Read the address from the domain outward.
In app.example.com, app is a name beneath example.com. That full hostname can identify a different service from www.example.com. The same naming hierarchy can extend further, such as preview.app.example.com.
Picture a studio that begins with a public website. Later it adds a customer dashboard and an API. Naming them www.example.com, app.example.com and api.example.com gives each part a recognizable address while keeping a shared identity. The names describe an arrangement; DNS and routing make it work.
Reference: MDN: domain namesA different name can lead to a different service.
A subdomain can resolve to the same host as the main domain or to infrastructure elsewhere. If several names reach one server, a web server or reverse proxy can use the requested hostname to choose the application. You do not automatically need another VPS for each subdomain.
Explore the studio’s service map below. Switching the address highlights the intended destination. The mapping is an example: you choose names that make sense for your product and configure both the DNS answer and the application route. A name on its own does not create the service.
app.example.com and example.com/app are different.
A URL includes a scheme, a hostname and often a path. In https://example.com/app, /app is a path under example.com. In https://app.example.com, app.example.com is the hostname. DNS resolves hostnames; it does not route individual URL paths.
Path-based organization can suit sections served by the same application. Separate hostnames can suit independently managed products or services. Either can involve routing configuration behind the scenes. Choose a structure your users and maintainers can understand, and plan redirects when changing existing addresses.
Reference: MDN: the parts of a URL| Address | What changes | Common interpretation |
|---|---|---|
| example.com/help | URL path | A help section within a website |
| help.example.com | Hostname | A separately addressed help service |
| api.example.com | Hostname | An API endpoint |
| example.com/api | URL path | An API routed beneath the main hostname |
Separate addresses need deliberate boundaries.
Browsers define an origin using the scheme, host and port. Two HTTPS subdomains have different hosts, so they are different origins. An app calling an API on another origin may need appropriate CORS configuration. Authentication and cookie scope also deserve an explicit design.
A subdomain is not a lock. A dashboard at admin.example.com still needs authentication and authorization. An obscure preview address can still become known. Use access controls that protect the service regardless of whether someone guesses its name.
Reference: MDN: browser originsGive every address an owner and a destination.
Keep a small inventory: the full hostname, the application it serves, its DNS record, certificate coverage and the person responsible. Mark whether it is production, preview or internal. This makes future migrations easier to review.
When retiring a service, remove or update the associated route and DNS entry deliberately. For a new subdomain, check the complete path from name to application. A working record, a valid certificate and a correct route are separate checks that should agree on the same destination.
Common questions.
Is www a subdomain?
Yes. www.example.com is a name beneath example.com. The bare domain and www can serve the same website, but they need the relevant configuration.
Do subdomains need separate domain registrations?
Normally you create them under a domain you control, without registering each name separately. DNS or hosting services can still have their own usage limits or charges.
Does a subdomain automatically keep an app private?
No. Privacy depends on network restrictions, authentication and authorization, not the name alone.
Connect the concept to your work.
DOCKOCK connects each hostname with its project and service route, keeping public websites, APIs and other application addresses understandable.
Explore subdomains in DOCKOCKKeep learning from the source.
Further reading from the teams and documentation behind these technologies.
MDN: domain namesMDN: the parts of a URLMDN: browser origins