Self-Hosted DNS and Domain Setup Checklist for Apps on Your Own Server

Overview

Use this article as a practical domain setup for self hosting checklist. The goal is simple: make every app reachable in a predictable, secure, and maintainable way.

At a high level, a clean setup usually includes five parts:

• A domain you control with access to its DNS zone.
• A naming plan for root domains, subdomains, and internal-only hostnames.
• DNS records that point traffic to the right public endpoint.
• A reverse proxy or ingress layer that terminates TLS and routes requests to the correct container or service.
• Operational habits for documenting changes, removing stale records, and revisiting assumptions.

Before you create records, decide what kind of self-hosting environment you actually have. Most setups fit one of these patterns:

• Single VPS with public IP: the easiest model for most internet-facing apps.
• Home server behind residential internet: workable, but shaped by NAT, ISP limitations, and changing IP addresses.
• Hybrid setup: some apps public on a VPS, some private at home, often connected through tunnels or VPN.
• Multiple hosts behind one domain: useful once you outgrow a single box.

If you are still deciding on your proxy layer, it helps to align DNS planning with the way you publish services. A stack built around labels and dynamic routing may favor a different naming pattern than a manually managed proxy. For that comparison, see Nginx Proxy Manager vs Traefik vs Caddy for Self-Hosted Reverse Proxy.

One rule stays useful in every environment: use DNS to describe intent, not infrastructure trivia. A subdomain like files.example.com ages better than dockerbox2.example.com. Infrastructure changes; service names tend to stay stable.

Checklist by scenario

This section gives you a scenario-based dns checklist self hosting readers can apply without guessing which records matter.

Scenario 1: Single VPS for public self-hosted apps

This is the cleanest starting point for a self hosted server. You have one public server, one reverse proxy, and several apps published under different subdomains.

1. Choose the primary domain.
   Use a domain you are comfortable keeping long term. If you may migrate providers later, keeping DNS independent from your compute provider can make moves easier.
2. Decide whether the root domain will host anything.
   You may use example.com for a landing page, dashboard, or redirect. If not, keep it simple and publish apps only on subdomains.
3. Create a record for the main public endpoint.
   Typically this is an A record to the VPS IPv4 address, and possibly an AAAA record if you use IPv6.
4. Create app subdomains.
   Examples: auth.example.com, files.example.com, git.example.com, status.example.com.
5. Point app records consistently.
   For one-host setups, either point each subdomain directly to the server IP or use CNAME records where appropriate if your DNS provider and record design allow it.
6. Route all web traffic through one reverse proxy.
   Let the proxy handle TLS and forward to app containers by hostname. This keeps exposure centralized and easier to audit.
7. Keep non-web ports private unless truly needed.
   For databases, admin panels, and internal APIs, avoid public DNS records if the service should not be internet-facing.
8. Test externally.
   Resolve the record, request the hostname over HTTPS, and verify the certificate and proxy target are correct.

Scenario 2: Home server with dynamic public IP

This is common in homelab apps and home server setup projects. The key difference is that your WAN IP may change, and inbound routing may be limited by your ISP or router.

1. Confirm inbound access is possible.
   Before touching DNS, verify you can actually forward ports 80 and 443 or use a tunnel-based approach. If inbound connections are blocked, traditional public DNS alone will not solve publication.
2. Use dynamic DNS only if needed.
   If your IP changes, automate updates to the relevant record. Keep the number of records tied to the changing IP small so changes are easier to track.
3. Separate public and private names.
   For example, public apps might live under app.example.com, while private-only services use internal naming or a split-DNS approach.
4. Do not expose router interfaces or infrastructure panels.
   Public DNS should point only to services meant for outside users.
5. Plan for tunnel or VPN access where it makes more sense than open ports.
   For admin dashboards, SSH, and internal tooling, a remote access layer can be safer and easier than public publication. See Cloudflare Tunnel vs Tailscale vs WireGuard for Secure Remote Access.
6. Document router dependencies.
   If someone else resets the router or changes forwarding rules, your DNS may still resolve while the app becomes unreachable.

Scenario 3: Multiple apps on one server with wildcard planning

If you expect to add many services, some operators use a wildcard DNS pattern such as *.apps.example.com. This can simplify growth, but it should be used intentionally.

1. Choose the wildcard boundary carefully.
   A dedicated zone like *.apps.example.com is usually cleaner than wildcarding the entire root domain.
2. Keep critical services on explicit records.
   For example, you may still want dedicated entries for status.example.com or auth.example.com.
3. Match wildcard DNS with your proxy capabilities.
   Your reverse proxy must still know how to route incoming hostnames, and your certificate automation must support the names you intend to serve.
4. Avoid using wildcard DNS as a substitute for inventory.
   It makes issuance easier, but it can also hide service sprawl if you stop tracking what is actually published.

Scenario 4: Hybrid self-hosting across VPS and home lab

This is often the most practical long-term model. Public apps live on a VPS, while storage-heavy or private apps stay on a home server.

1. Split services by exposure level.
   Public websites, status pages, and customer-facing tools fit well on a VPS. Personal dashboards, backups, and admin interfaces often belong on private networks.
2. Use subdomains to reflect service role, not location.
   photos.example.com is better than home-photos.example.com unless location truly matters.
3. Point each hostname to the correct public entry point.
   Some subdomains may go to the VPS IP, while others may terminate through a tunnel or alternate edge endpoint.
4. Keep your routing map written down.
   A simple table of hostname, DNS target, proxy target, and service owner prevents confusion later.
5. Review failover expectations.
   DNS is not high availability by itself. If a service moves from home to VPS during an incident, document the change sequence in advance.

Scenario 5: Self-hosting with management platforms

If you deploy through Portainer, Coolify, CapRover, or a similar control plane, the domain checklist still matters. These tools can automate parts of publication, but they do not replace naming discipline.

1. Reserve a management subdomain.
   Use something obvious like panel.example.com or a dedicated management domain.
2. Keep app domains separate from admin domains.
   A clean boundary reduces confusion and makes access control easier.
3. Understand how the platform expects DNS to work.
   Some platforms are happiest with explicit records; others work well with wildcard subdomains.
4. Do not let convenience create messy naming.
   Auto-generated hostnames are fine for testing, but production names should stay readable and durable.

If you are choosing a platform, compare the operational tradeoffs in Portainer vs Coolify vs CapRover: Which Self-Hosting Control Panel Fits Best?.

What to double-check

These are the details that cause the most avoidable trouble in a self hosting domain guide. Run through them before you call a setup finished.

• DNS records match the intended endpoint.
  Make sure you are pointing to the public address or edge service that actually receives traffic, not the container's internal IP.
• TTL values fit the situation.
  Long TTLs reduce query churn, but they also slow down changes. Shorter TTLs can help during migrations, then be raised again once stable.
• Every public hostname has a clear owner and purpose.
  If you cannot explain why a record exists, it may be stale.
• Certificates cover all published names.
  DNS can resolve correctly while HTTPS still fails because the certificate scope is wrong.
• IPv6 is either fully supported or intentionally omitted.
  Publishing an AAAA record without working IPv6 connectivity can create hard-to-diagnose partial failures.
• Proxy routing matches DNS hostnames exactly.
  A hostname that resolves but is not configured in the reverse proxy often lands on the wrong backend or a default page.
• Split-horizon or internal DNS behavior is documented.
  If internal users resolve a hostname differently from external users, note it clearly so troubleshooting stays sane.
• Monitoring checks the real public hostname.
  Monitor the same URL your users depend on, not just container health. For ideas, see Best Self-Hosted Monitoring Tools for Small Servers and Homelabs.
• Backups include DNS documentation.
  Your registrar and DNS provider may not be part of your normal server backup process. Keep an export or written record of your critical zones. Pair this with your broader recovery plan using Self-Hosted Backup Strategy Checklist for Docker and VPS Servers.
• Credentials are stored safely.
  Losing access to your registrar or DNS provider can be worse than losing one server. A reliable password manager matters here; see Best Self-Hosted Password Managers Compared.

It also helps to maintain a small inventory document with four columns: hostname, DNS record target, reverse proxy destination, and notes. That single sheet often prevents hours of guesswork.

Common mistakes

Most DNS problems in self-hosting are not exotic. They come from a few recurring habits.

• Using inconsistent naming across apps.
  If some services use product names, others use container names, and others use vague labels like server1, your setup becomes harder to maintain.
• Publishing everything publicly by default.
  Not every service needs a public DNS record. Admin dashboards, metrics endpoints, and databases usually should not have one.
• Mixing testing and production in the same namespace.
  Create a distinct pattern for experiments, such as dev.example.com or *.lab.example.com, so temporary services do not pollute your main domain.
• Forgetting that DNS is only one layer.
  A record can resolve correctly while the firewall, router, proxy, certificate, or container port is wrong.
• Leaving stale records behind after migrations.
  Old subdomains can confuse users, break certificates, and create unnecessary exposure.
• Pointing the root domain at infrastructure just because it is possible.
  If the root domain has no clear use, a simple redirect or static page is often cleaner.
• Exposing vendor or environment details in hostnames.
  Names like aws-prod-node2.example.com can leak more about your setup than needed, while also aging badly when infrastructure changes.
• Skipping basic host hardening.
  A neat DNS layout does not compensate for an insecure server. Review the basics in How to Set Up a Secure Ubuntu Server for Self-Hosting.

A useful habit is to review your active DNS records quarterly and ask two questions for each one: does this still need to exist, and who would notice if it broke? Records that have no clear answer should be investigated.

When to revisit

DNS and domain planning is not a one-time task. Revisit it whenever the surrounding workflow changes. This keeps your self hosted dns setup aligned with reality instead of becoming a pile of old assumptions.

Good times to review your setup include:

• Before adding a new public app.
  Check whether it fits your current naming pattern, proxy layout, and exposure policy.
• Before migrating from home server to VPS or the other way around.
  Lower TTLs ahead of time, confirm cutover order, and keep rollback notes ready.
• When changing reverse proxy tools.
  Host-based routing, wildcard support, and certificate workflows may change.
• When adopting a control panel or platform.
  Automation can alter how domains are requested, provisioned, and renewed.
• At the start of a cleanup cycle.
  A seasonal review is a good time to remove dead apps, retire stale records, and update your documentation.
• After any incident involving certificates, routing, or downtime.
  Even small outages often reveal naming or documentation problems worth fixing.

For a practical review routine, use this short action list:

1. Export or copy your current DNS zone.
2. List every public hostname you actively use.
3. Map each hostname to its proxy target and server location.
4. Delete or archive stale records.
5. Check certificates and HTTPS behavior for each public app.
6. Verify monitoring covers the important hostnames.
7. Update your runbook with any changes.

If you maintain a dashboard for your services, this is also a good moment to align visible links with the hostnames users should actually bookmark. A dashboard can reinforce clean naming if it mirrors your domain structure; for examples, see Self-Hosted Dashboard Tools Compared: Homepage vs Homarr vs Dashy.

The most durable approach is not the most clever one. It is the one you can understand six months from now, migrate without drama, and explain to another administrator in a few minutes. If your DNS layout supports that, your self hosting domain guide is doing its job.