xhostd vs. a self-managed VPS

Renting a virtual private server (VPS) and deploying on xhostd end in the same place: your application runs on a Linux machine and answers on HTTPS. They differ in who operates the parts around it. This article names those parts and says who owns each one, so you can decide from the work rather than from the price.

Neither answer is the correct one for everybody. A team that needs to control the kernel, the filesystem, or the exact Postgres build should run its own server. The comparison is about what you take on when you do.

The parts you have to place somewhere

Every deployed web application needs the same seven things, whoever runs them:

• a process that stays up, and restarts when it stops;
• a certificate, renewed before it expires;
• a database, if the application stores anything relational;
• a backup of that database, taken before you need it;
• somewhere durable to keep uploaded files;
• a way to ship a new version without a hand-copied file;
• an operating system that keeps receiving security updates.

On a VPS you own all seven. On xhostd you own the first — your application's code — and the platform owns the other six.

What the VPS asks of you

Certificates. A reverse proxy can do this well. Caddy obtains and renews certificates with no configuration beyond the hostname, so the day-one cost is small. The cost arrives later: certificate authorities publish rate limits, and Let's Encrypt is no exception. Reaching one while you are reissuing under pressure means waiting, and the waiting happens during the incident rather than before it.

Postgres backups. pg_dump on a timer is a backup of yesterday. Recovering to a point between two dumps needs continuous write-ahead log archiving, and PostgreSQL requires you to configure that before the loss, not after. The archive also needs somewhere off the machine to live, and a restore you have actually rehearsed.

Operating system currency. An Ubuntu LTS release carries five years of standard security maintenance. That is a long time, and it is not forever: at the end of it you upgrade the machine in place, rebuild it, or buy extended support. The work is small in any one year, which is what makes it the kind of work a team postpones until the year it cannot.

The deploy step. Copying a build over SSH works until two people do it, or until you need the previous version back in a hurry.

None of this is beyond an ordinary team. All of it is yours, and it keeps being yours on the days you would rather be writing the application.

What xhostd operates instead

Every channel — xhostd's word for one running environment of one app — starts with HTTPS on a hostname the platform issues. Attaching a domain you own takes two DNS records and a verification call; the certificate is minted on the first HTTPS request and renewed without you. A channel accepts up to five custom domains. The custom domains page has the procedure.

Every code-running template gets its own Postgres database, with connection settings already in the environment. Static sites get none, because they store nothing. The Postgres recipe covers schema migrations and access.

Backups are nightly, and xhostd takes a separate recovery point before each deploy. Retention is 24 hours on the free plans and 7 days on the paid ones; the pricing page states the figure per plan, and the backup FAQ states the policy. Read Data and recovery before you rely on a particular recovery window: a checkpoint with no aligned file marker is not an atomic restore of the whole application.

Each channel also gets S3-compatible file storage and, if you want it, Google sign-in for your end users. A deploy is a git push followed by a deploy call, which an agent can make on its own.

Where the two land on the same answer

• Your code. It is the same application either way. xhostd runs ordinary containers, so nothing about the code is platform-shaped.
• Your data's format. Postgres is Postgres. A dump taken on xhostd restores onto a server you rent, and the reverse.
• Custom domains and their certificates. Both reach the same result. The difference is whether renewal is something you watch.

Costs that are not the monthly bill

A VPS quote is the machine. The comparison a monthly price misses is the hours: the initial setup, the upgrade you postpone, the backup you discover was never running, and the evening a certificate expires. Those hours are real and they are unevenly distributed — mostly zero, occasionally an entire day.

A managed platform charges for the operating as well as for the machine, and that is the trade being made. Compare the two totals, not the two machines: read the pricing page beside a server quote and beside your own estimate of the hours.

Which one to pick

Pick a self-managed VPS when you need control the platform does not offer: a specific kernel, a specific Postgres extension, custom networking, or a compliance regime that names the machine. Pick it also when operating servers is work your team already does well, because then the marginal cost really is close to the quote.

Pick xhostd when the application is the point and the machine is not — and especially when an AI agent is doing the building, because the agent can create the app, push the code, and deploy without a human provisioning step in the middle. Getting started is the shortest path to a running URL.