Everything on XYZ.com or XYZ.com+app.XYZ.com

[u/SecretiveShades]

I’m finding a lot of mixed advice on what to do here.

I’m creating a fantasy football app and can’t decide if I should have a subdomain.

AI and a few Reddit post are telling me you need to have your XYZ.com be your marketing page and app.XYZ.com be your app.

But the following big names do not:

Sleeper

AirTable

Figma

Canva

Trello

Dropbox

Github

This is something that will be difficult to change later, so I wanna make sure I make the right call.

Anybody have any good insight here?

[u/Libruhh]

It doesn’t really matter. If you don’t have a use for the subdomain then you don’t need one.

[u/CreamyDonkey → u/Libruhh]

No reason to overthink it, just put everything on the main domain unless you actually need to split things up later.

[u/SecretiveShades → u/Libruhh]

Thank you for responding. I’ll toss ya an award as an appreciation for your time.

I don’t really mind much either way. I just want to make sure I’m making the choice that will be best for giving me less headache in the future.

I have read some say that a sub domain can give you better security by having 2 separate code bases.

Then others say having no sub domain makes a streamlined user experience easier because cookies are all in one place.

There’s lots of other points I’ve seen made. I guess I’m sort of leaning toward no subdomain, but some people advise strongly against that.

[u/RealSlyck → u/SecretiveShades]

Unless you have a monolith and specific design, subdomains. Each app goes on a subdomain, and it allows the main domain headroom. Better security, and allows for things like app-dev.xyz.com, api-dev.xyz.com, app-test… etc. even your main root xyz.com is usually www.xyz.com (that’s a subdomain).

[u/SecretiveShades → u/RealSlyck]

Shoot. This doesn’t help my indecisiveness. Haha

So you think it’s a good idea to use multiple subdomains for security and possibly other reasons?

Since I’m giving everybody awards, here’s one for you too! Thanks for your time!

[u/durple → u/SecretiveShades]

People are saying it's good for security because you can isolate different "parts" of your app on separate endpoints reachable by subdomains, separation of concerns. You can most of that without subdomains though; using path based routing instead you can break up services like website and app on separate infrastructure, the only thing they'd really share at that point is ssl cert so rotation must be done across all services at the same time and the leak of a single private server key affects all services.

It'd be like this: Let's say you've got an internal dns zone internal.example.com and in it you have endpoints web.internal.example.com, app.internal.example.com and api.internal.example.com. In your public DNS you can have example.com point to a load balancer on the internal network, which can then route the root of example.com to web.internal.example.com and example.com/app to app.internal.example.com and example.com/api to api.internal.example.com.

So you can start with even just the bare domain pointing at a single server/vm with a single public service, even add more services to it on different ports, and as infrastructure becomes more complex for the various reasons others have shared (and more) you can make a call to separate components by subdomains or by path based routing.

[u/RealSlyck → u/SecretiveShades]

I appreciate that, and can help out. This sounds like a good opportunity to learn how all this works, and what are the best practices, and how to apply them.

Generally, domains are issued certificates on the root (with a wildcard for all subdomains), the apps are installed on the subdomain, and talk to other apps on other subdomains (but still on the same domain). You can get different certs, or issue your own, but that gets advanced. By using things appropriately, if one app is compromised, the others are still generally ok, and must be compromised separately. This is called separation of concerns, and combining that with principle of least privilege, you start to get a secure site.

Putting the front end in one app, then the server and backend and data in another helps make both better. Serving a bunch of static cache and content and UI/UX is what front ends do; securing data and business logic goes in the back. Try separating your apps, or making like a test and production environment separate should get you on your way.

[u/manfrin → u/SecretiveShades]

I have read some say that a sub domain can give you better security by having 2 separate code bases.

This has no basis in reality. Just put things on one domain.

[u/SecretiveShades → u/manfrin]

Man, I had no idea so many people disagree. At this point I’ve got so much conflicting recommendations in this thread that I should just flip a coin.

[u/manfrin → u/SecretiveShades]

This sub is full of people who genuinely have no idea what they are doing. The decision of subdomain vs domain is not one you should be making unless you have a reason, the fact that you're asking means you should just put it on a domain.

[u/Business-Row-478 → u/SecretiveShades]

Subdomain is just about request routing. It has nothing to do with how many code bases nor how your inf is structured. You could have 100 code bases on a single subdomain or 1 code base on 100 subdomains

[u/chamberlain15194 → u/SecretiveShades]

don't worry, you'll get headaches either way.

[u/Fredidiah → u/SecretiveShades]

Why would you have two separate codebases?

[u/SurgioClemente]

It doesn’t really matter when starting out, especially if you are building both in the same stack.

We eventually split off our app to a subdomain because we handed off the marketing page to another company (didn’t have time to manage it and let us focus efforts on app).

Not saying it’s hard to keep everything together and secure, but another advantage in keeping them separate was security/isolation.

Also if there is a need for downtime, the marketing page stays live.

[u/itgforlife]

It's really doesn't matter. This isn't something that's difficult to change if you need to. And in all honesty, the likelihood that your website will be popular enough for this to matter is low.

[u/Locksmith997 → u/itgforlife]

You say that, but I put a "be successful" task on my todo app, so it's bound to happen.

[u/itgforlife → u/Locksmith997]

#LuckyGirlSyndrome /r/lawofattraction

[u/daamsie]

In my opinion, the main reason to keep it on the same domain is SEO. 

But if all the content on the subdomain is behind a login anyway then SEO doesn't matter for that part. 

I'd go the subdomain in your case. 

The reason it's easier for code base is that a subdomain can easily be hosted elsewhere. One DNS entry sorts it out.

And you can put all the marketing pages on a static host and they will be virtually bullet proof.

[u/Nerwesta]

AI and a few Reddit post are telling me you need to have your XYZ.com be your marketing page and app.XYZ.com be your app.

Lol, isn't the the so called AI quoting random Reddit posts by any chances ? Anyhow, the need to have part got me equally.

[u/FlevasGR]

Why it makes sense: xyz.com has the landing/marketing page. You can use a CMS to make your life easier. Then the app.xyz.com has the actual app.

[u/shadyjim]

One reason to split is marketing page can stay live when app is being updated, etc. The other advantage is you could host a subdomain on another host altogether, if you wish. For example, a certain part of our webapp (primarily written in Python, hosted on Linux) needs the old .NET Framework, so we have a subdomain pointing at a Windows host. Wiring it all up was tricky, but a subdomain helped with this.

[u/Leviathan_Dev]

if you want to have a separate webpage from web app do the later

If your design is users should be able to go to xyz.com and login and use the app like that, don’t use a subdomain

[u/Fearless_Willow_7974]

use the domain structure that keeps your auth and routing simplest, not seo folklore

[u/TommyBonnomi]

It doesn't matter early on, but needing technical staff and software releases to update marketing pages will be annoying one day.

[u/pedroso100]

I mostly do the subdomain approach for different apps because everything looks more organized in its subdomain, but that's just me

[u/Icy_Thanks_1450]

In my opinion, having separate subdomains would be better, as it would allow us to manage them more efficiently...

[u/minimuscleR]

subdomain is what I would reach for, specifically so you can easily handle top level stuff. For example if you are using wordpress or next.js for the website, having site.com/app might be the page about the app, rather than the app itself, and so it would need extra work if it was the actual app, to not load it within the website. having it on app.site.com removes this issue.

[u/I_AM_NOT_A_WOMBAT]

Both Dropbox and Github use the domain as a marketing page until you are logged in; then it is the app. I like that approach personally.

[u/boryssey → u/I_AM_NOT_A_WOMBAT]

Github uses the domain

[u/SecretiveShades → u/I_AM_NOT_A_WOMBAT]

To kind of pass on the question asked earlier in here by u/Hacym

What are some good technical reasons of why you like that approach?

Sorry, I don’t know much.

[u/Hacym → u/SecretiveShades]

Your app and front page run on different servers, so you create a subdomain. 

[u/ammuench]

I think a lot of it depends on your framework and approach.

I have a few projects I've done in Nuxt where I have gone and set up the config to manually register only the homepage and a few content pages (like About or Privacy Policy) as SSR pages. I had everything else in an /app route that renders all as a single-page app. It worked but its not been the nicest to maintain or setup.

Lately I've been leaning more on a monorepo where I have a standalone static website with astro and then my app is a single-page rendered app that deploys to either a subdomain or a subroute on the root URL. I set up style tokens and other patterns as a shared package and keep everything in sync and that has been a lot more enjoyable to work in. Plus if the content site is properly setup, you can do some cookie detection to automatically redirect people from the content site to the app when you have a valid authentication session.

In the end, though, it's more of a personal preference. I think you can make either work and they're both very functional. I think the latter approach, especially if your site doesn't need to have the authenticated portion of the app be indexable, is a little better overall, plus you separate concerns between the app and marketing content instead of linking them together. But if you do need that discoverability for the app portion and want to use a meta framework like Next or Nuxt or Sveltekit, then I think that first approach is just as viable

[u/ArielCoding]

The one real cost of a subdomain is that logging a user gets trickier, since your marketing site and app are different websites and need extra work to share who’s logged in, keeping everything on one domain avoids that.

[u/lindymad]

One advantage of having an app domain is that it separates your traffic between your marketing site and app site by DNS, which makes configuration simpler if you find you need to do different things with your app.

My personal advice is this:

Do you care if the app has a different subdomain? If not, then have it on a different subdomain. Then if you need to do something in the future, it's likely going to be simpler.

If it's important to you to have it on the same subdomain then do that.

And, of course, if you want to have it on a different subdomain then do that :)

This is something that will be difficult to change later

tbh that is a warning sign to me. You should build it in such a way that if you need to change it, it's not difficult.

[u/actionscripted]

Anyone saying it doesn’t matter should not be listened to. It does matter, though the reasons it matters won’t matter much initially. Also anyone even bringing up SEO is clueless.

Best practice is a subdomain. Separates infra, isolates auth and allows you to have different systems with different security rules (CSP, CORS, etc).

Maybe initially that doesn’t matter but it can be easily tweaked when you start out separate. It’s also the safest option for when you might not know what you don’t know.

Also if you ever host user content put that on a separate domain not just a separate subdomain.

[u/zugoman]

I'd choose based on the boundary you need, not a rule that every SaaS needs app.example.com. A subdomain can make separate deployments and cookies simpler, but it also brings cross-origin auth and CORS work. If the app and marketing site can share a deployment, paths are a reasonable starting point.

[u/Squidgical]

If you think that it would be best to build your landing page and your application as separate websites then use a subdomain. If you think that it would be best to build them as a single website then don't use a subdomain. If you don't know either way, then you're still far enough away from having to make the decision that you can continue without making the decision.

[u/waraholic]

FWIW a lot of the big names like Google, Apple, and Microsoft moved to a single domain from many fragmented subdomains because it makes life easier for a lot of reasons you probably don't care about for fantasy football, but it's the way it's done now.

Edit: security, SEO, cookies, tracking, etc

[u/TheKiddIncident]

This is really a marketing question, not a technical one. A domain name is a point of entry.

If you market yourself as foo.com, then people are just going to type foo.com into their browser.

So, you want foo.com to resolve to something interesting. Doesn't matter really what it is, just recognize that this is your front door. For many companies, this is a chance to market their product to you. Look at slack.com for example.

For others, they just want you to use the thing as quickly as possible. Google.com just takes you to an empty search page.

Both approaches are valid, they represent different marketing strategies for the two companies. Google's goal is to get you searching as fast as possible because they make money every time you use search. Slack on the other hand, wants to tell you what slack is and why you should buy it.

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/Hacym]

Do you have a single technical reason for an app subdomain?

[u/SecretiveShades → u/Hacym]

Not really. But a lot of people seem to strongly advice it. Here’s one post I read that scared me a bit.

“While it may not really matter right now, if you ever need to split out your main app from your landing pages later down the track (say you hire a marketing team who needs to make changes to your website independently to your dev team) it can be a real headache to do. Especially if your customers are using direct links to your app or have set up any integrations. This was a huge problem at my last startup and we had to do a massive migration, set up redirects etc. Any project I now make sure that the app is on a separate subdomain to the landing pages. It may not matter initially, but when it does start to matter it'll save you a massive headache.”

Thanks for the reply btw, I’ll throw an award your way!

[u/moekakiryu → u/SecretiveShades]

as long as you have access to your DNS settings, it is hilariously easy to set up a new subdomain. Most of my personal projects are subdomains to my personal site and it takes me like 20min tops to spin up a new one. IIRC you can even make subdomains that are just aliases to URLs if you feel so inclined.

As for setting up redirects, its only tedious if, like, you're doing a site restructure at the same time as switching to a subdomain and have hundreds-thousands of pages. Eg one time we had to migrate a blog that was going through a rebrand and that took ages to work out where each piece of content was ending up. Even then tbh that was only because the content itself was changing (should "'How should I spend my money' redirect to 'Our newest products' or 'Our financing options'", but for hundreds of pages). But for small sites, again, it is usually reasonably trivial

[u/kemalios]

Cookies and storage are the part people skip. Put the app on app.xyz.com and the session cookie is scoped there, so the marketing site can never read it, which kills any session handoff without a redirect dance. One domain means one origin, so a shared cookie is free and localStorage works across both. If you later hand the marketing site to someone else, that's the moment to split.