How we host this site (and why on a VPS)

We’re a company that runs apps on a VPS. So people reasonably assume this website runs on a VPS too. It doesn’t. This marketing site is deployed on a static-site host, and that’s a deliberate choice, not a contradiction. Let me explain the split honestly, because a hosting company being cagey about its own hosting would be a bad look.

Two different jobs

The key idea is that “the site” and “the product” are two completely different things with different needs. Using the same tool for both would be dogma, not sense.

This website is a marketing site. It’s pages: what we do, pricing, these blog posts, an about page. It reads from files, not from a live database. Nobody’s data lives in it. If it went down for ten minutes, some visitors would see a page fail to load and that’s the whole cost. No one loses anything.

The product is where we run our customers’ apps. That’s live software with real users and, crucially, real databases full of real data. If that goes down, people lose access to their app, and if data were mishandled, they could lose something they can’t get back. The stakes are in a different universe.

Same word, “hosting,” two jobs that share almost nothing. So they get matched to two different tools.

Why this site is on a static host

This site is built with Astro and Tailwind. Astro compiles it down to plain static files: HTML, CSS, a little JavaScript. There’s no server-side database, no per-user state, nothing that needs a machine I control at the OS level.

For that kind of static site, a managed static-site host is a great fit and honestly the boring, correct answer:

Push to Git, it deploys. I commit a change, the platform builds the site and ships it. No server to configure, no certificate to renew by hand.
HTTPS is automatic. Certificates just work. For a static marketing site, there’s nothing here worth doing myself.
There’s no database to protect. The entire reason I’d want to own the server, control over data and backups, doesn’t apply. There’s no customer data on this site to lose.

This was a specific decision, made deliberately and scoped narrow: a static host serves the marketing site, and that’s all. It is explicitly not where the product runs. Reaching for a full VPS setup to serve a handful of static pages would be me doing extra work to prove a point, and paying in complexity for nothing. That would be dogma. The whole site is just files. Files want a static host.

Why the product stays on a self-managed VPS

Now the other job, and here the reasoning flips completely.

The product runs our customers’ live apps and their databases. For that, the things I don’t care about for a static site become the entire point:

Control over the data. We run our own Postgres so we own the backups, the point-in-time recovery, the retention, and where the data physically sits. That’s the core promise. You can’t outsource it to a platform’s default policy.
Cost at real scale. A VPS gives you serious compute for a few euros a month, a fraction of the equivalent managed cloud bill. For hosting real apps continuously, that gap is the business.
EU data residency. Our servers sit in EU data centers, which keeps EU customer data in the EU by default and makes GDPR far simpler.
A surface I fully understand. Docker, Caddy, Postgres on a Linux box I control top to bottom. When something breaks at 3am, owning the whole stack matters.

None of those reasons apply to a static marketing site. All of them are decisive for a product that holds people’s data. I laid out the full case in why we chose a VPS over a big cloud.

The principle underneath

The takeaway isn’t “the static host is good, the VPS is good.” It’s match the tool to the actual job.

A static site with no data wants the simplest thing that ships it reliably. That’s a managed static host. A live product holding customer data wants control, low cost at scale, and data residency you own. That’s a self-managed VPS. Forcing either job onto the other tool would be a worse decision made to look consistent.

This is the same thinking we bring to customer apps. We don’t have one answer we bolt onto everything. We look at what the app actually needs and pick accordingly. A company that reached for its heaviest tool to serve five static pages would be exactly the kind of over-engineering we try to save our customers from.

The honest version, plainly

To leave zero ambiguity, since honesty about our own setup is the point:

This website, stackbastion.com, is a static site deployed on a managed static host. It holds no customer data.
The customer-facing product, where we run and protect your app and its database, runs on a self-managed VPS with Docker, Caddy, and our own Postgres. Unchanged.

Two jobs, two tools, one principle. If you want the product side, the part where we actually keep your app alive and your data safe, that’s what our pricing covers.

FAQ

Wait, so you don’t even host your own site on the same VPS as customer apps?

Correct, and on purpose. This site is static files with no database, so it goes on a managed static host, which deploys it from Git with automatic HTTPS. The product, which holds real customer data, runs on a VPS where control over that data actually matters. Different jobs, different tools.

Isn’t that inconsistent for a VPS-based company?

It would be inconsistent to force a static marketing site onto a full server setup just to look consistent. The consistent principle is matching the tool to the job. A no-data site wants a static host. A data-holding product wants a server we control. Same principle, two answers.

Does my app run on the same static host too, then?

No. Customer apps run on a self-managed VPS with Docker, Caddy, and our own Postgres. The static host is only for this marketing site. Your app and its database live on the VPS side, where we own the backups, monitoring, and data residency.

Why does the difference matter to me as a customer?

Because it shows how we think. We don’t bolt one heavy solution onto every problem. For your app, we pick what it actually needs rather than what sounds impressive. The reasoning behind the product side is in why we chose a VPS over a big cloud.