Don't Self-Host Until You Understand These 7 Things

This isn't a hazing ritual for people who want to run their own server. It's a genuinely useful question to ask yourself before you do: could I explain each of these seven things to someone else, not just recognize the term when I hear it? Recognizing "reverse proxy" and being able to explain what specifically breaks without one are different levels of understanding, and the gap between them is exactly where a self-hosted app tends to fail in ways a managed platform would have absorbed silently.

None of these are advanced. All seven are things a competent managed platform quietly does for you, which is precisely why they're easy to go years without learning even as a working engineer. Self-hosting doesn't require a computer science degree. It requires knowing these seven things well enough that when one of them goes sideways at an inconvenient hour, you recognize what's happening instead of guessing. XenGrowth's marketing operations practice writes about don't self-host until you understand these 7 things as an operating problem rather than a build problem.

Do you actually understand how DNS propagation works, or just that it's slow?

"DNS takes a while to propagate" is the thing everyone repeats and almost nobody can explain. The real mechanism is caching, not propagation in any physical sense — every resolver between a visitor's browser and your authoritative nameserver caches the answer for however long the record's TTL says to, and it keeps serving that cached answer until the TTL expires, regardless of what the record now actually says. Change an A record and set TTL to one hour, and some resolvers will keep answering with the old IP for up to an hour after the change, purely because they haven't been told to check again yet. This matters practically the moment you migrate a domain to a new server: lower the TTL a day in advance if you can, expect a mixed window where some visitors hit the old box and some hit the new one, and never assume a DNS change is live everywhere the second you save it.

There's a second, less-discussed layer underneath that: negative caching. A resolver doesn't just cache the record you gave it — it also caches the fact that a record doesn't exist yet, for a duration set by the SOA record's own TTL, which is often longer than the individual record TTLs on the zone. Add an A record too early, before you're ready to point traffic at it, and check from the wrong resolver, and you can get a cached "no such record" answer that outlives the record's actual creation by hours. This is the mechanism behind the classic "I added the record and it still says not found" confusion, and knowing it exists saves an afternoon of re-adding a record that was fine the whole time.

What does a TLS certificate actually prove, and what does it not?

A padlock in the address bar proves two narrow things: the connection between the browser and the server is encrypted, and a certificate authority validated that whoever requested the certificate controlled the domain at the moment it was issued. That's the entire claim. It says nothing about what software is running behind that connection, whether it's patched, or whether the operator is trustworthy — a phishing site can have a perfectly valid certificate for its own look-alike domain, because domain-validated certificates were never designed to vouch for content or identity, only for domain control and transport encryption. Understanding this distinction matters for your own box too: getting HTTPS working with Let's Encrypt is a solved, largely automatic problem, and it's tempting to treat "certificate issued" as "server secure." It isn't. It's one narrow box checked, not the whole checklist. The XenGrowth resource library goes further into the operations side of this.

Do you understand the Linux process and service model well enough to keep something running?

• A process started directly in an SSH session is a child of that shell — close the terminal, and depending on the shell and how the process was started, it can die with it. This is the single most common "why did my app stop when I wasn't even doing anything" moment for someone new to running a server.

• A service manager (systemd is the one you'll actually meet) exists specifically to detach a process's lifecycle from any particular login session, restart it if it crashes, and start it automatically on boot — none of which happens for free just because a process is technically running.

• Docker changes this picture but doesn't remove it: a container with no restart policy set stays dead after a crash or a host reboot, and `restart: unless-stopped` or `restart: always` in a compose file is the thing standing between a transient crash and an outage that lasts until someone notices.

• Logs, by default, go wherever the process's stdout/stderr happens to be pointed — a terminal, a file, or (inside Docker) the logging driver — and understanding where they're actually landing is the difference between debugging a 3am incident in five minutes and in an hour.

• None of this is exotic knowledge — it's the same handful of concepts systemd, Docker, and every process supervisor are built around — but it's also the layer a managed platform hides completely. You never think about restart policies on a platform that restarts things for you by design. Self-hosting means that design decision becomes yours.

What is a reverse proxy actually doing that your app couldn't do itself?

A reverse proxy sits between the internet and your application process, terminating TLS, routing requests to the right service by hostname, and absorbing the kind of hostile or malformed traffic an application server was never built to handle gracefully on its own. This isn't a self-hosting-specific opinion — it's the documented recommendation for running Next.js in production outside of Vercel: put a reverse proxy in front of `next start`, specifically for malformed requests, slow-connection attacks, payload size limits, and rate limiting, so the app process spends its resources rendering pages instead of defending itself. Skip this layer and every one of those problems still exists, just with your application code as the last line of defense instead of the first.

Concretely: a client that opens a connection and trickles in one byte every few seconds can tie up a naive application server's connection pool for as long as it's willing to wait, because the app was written to assume requests arrive at normal speed. A reverse proxy with sane timeout settings closes that connection long before it becomes a problem, without the application ever needing to know the attack happened. Nothing about this requires the proxy to be complicated — Traefik, Caddy, and nginx all do this by default with reasonable settings — it just has to actually be there, in front of the app, rather than assumed.

Which parts of a Docker container actually persist, and which vanish on restart?

This is the one people think they understand and genuinely don't, until it costs them something. Anything written to a container's own writable layer — the filesystem inside the container that isn't explicitly mounted from the host — is gone the moment that container is removed with `docker rm`, even if it survived a simple restart. Data written to a named volume or a bind mount lives on the host, outside the container's lifecycle entirely, and survives the container being deleted and recreated. Confusing these two is how a database "just running in a container" with no volume configured loses everything the first time someone runs `docker compose down` instead of `docker compose stop` — the command that looks like a harmless cleanup step is, for un-mounted data, indistinguishable from deleting it on purpose. There is a longer treatment of AI agents and marketing automation in XenGrowth on governed AI marketing workflows.

Do you know the actual difference between a backup, a snapshot, and replication?

These get used interchangeably in casual conversation and they protect against genuinely different failures, which is why conflating them is dangerous rather than merely imprecise. A backup is an independent, portable copy of data taken at a point in time, stored separately from the system it came from, and usable to restore onto a completely different machine. A snapshot is typically provider-specific and tied to the same infrastructure or account the original lives in — fast to take and restore, but often useless if that provider account or region has the problem. Replication keeps a second copy continuously in sync with the first, which protects against hardware failure but actively works against you in the one scenario backups exist for: if bad data or a destructive command replicates before anyone notices, replication faithfully copies the mistake too.

The practical takeaway isn't "pick one." A serious self-hosted setup usually wants at least two of the three, because they cover different failures: replication (or just a solid uptime story) for hardware death, and an independent, off-site backup for the mistake that replication would otherwise faithfully copy. Snapshots are a nice-to-have on top, not a replacement for either.

Are you actually ready to be the on-call engineer, with no one to escalate to?

This is the item that isn't really technical, and it's the one that changes the most day to day. On a managed platform, an outage at 3am is someone else's alert, someone else's incident, someone else's postmortem. Self-host, and the alert — if you've even set one up — is yours, at whatever hour it fires, with no senior engineer to escalate to and no support ticket that gets a response in twenty minutes. That's not a reason not to self-host. It's a fact worth being honest about before the first real incident, rather than discovering it during one. Some people read this and decide the trade is worth it. Some decide it isn't yet, and that's not a lesser answer — it's the correct answer for a lot of teams and a lot of stages of a project. For the AI search, GEO and discovery angle, see XenGrowth on building one SEO and GEO content system.

This is also where the other six items on this list stop being abstract. Being the on-call is the reason DNS caching behavior matters at 2am during an emergency migration, the reason a silently failed cert renewal is a customer-facing incident and not a Tuesday afternoon fix, and the reason "the container just restarted and the data's gone" is a sentence you'd much rather never say out loud. Each of the previous six items is, in a real sense, a way of making the seventh one less painful.

So what if several of these are genuinely new to you?

Then stay on a managed platform for now, and mean it as a strategic choice rather than a concession. None of these seven things are unlearnable, and there's no deadline forcing the decision — every one of them can be learned deliberately, on a low-stakes side project, before the box in question is holding anything a real customer depends on. What's actually risky isn't self-hosting itself. It's self-hosting something that matters while treating these seven as details to pick up later, because "later" tends to arrive in the form of an incident rather than a study session. The full mechanism behind the on-call reality — what it looks like in practice, not just as a warning — is in the checklist for securing a fresh VPS, and the companion question worth asking once you do decide to self-host is covered in the rule for deciding what to self-host and what to keep paying for.

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.

• XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.

Where this work meets go-to-market

the team at XenGrowth covers the go-to-market side of don't self-host until you understand these 7 things, which this piece deliberately leaves alone.