How we host this site (and why the product itself still runs on Hetzner)

We’re a company that runs apps on Hetzner. So people reasonably assume this website runs on Hetzner too. It doesn’t. This marketing site is deployed on Railway, 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 Railway

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, Railway is a great fit and honestly the boring, correct answer:

• Push to Git, it deploys. I commit a change, Railway 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: Railway hosts the static marketing site, and that’s all. It is explicitly not where the product runs. Reaching for a full Hetzner 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 Hetzner

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 Hetzner box 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. Hetzner’s data centers are in Germany and Finland, 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 Hetzner over AWS, GCP, and Azure.

The principle underneath

The takeaway isn’t “Railway good, Hetzner 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 static host like Railway. A live product holding customer data wants control, low cost at scale, and data residency you own. That’s Hetzner. 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 Railway. It holds no customer data.
• The customer-facing product, where we run and protect your app and its database, runs on Hetzner with Docker, Caddy, and our own Postgres. Unchanged.

Two jobs, two tools, one principle. If you want the Hetzner 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 Hetzner?

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

Isn’t that inconsistent for a Hetzner-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 Railway too, then?

No. Customer apps run on Hetzner with Docker, Caddy, and our own Postgres. Railway is only for this static marketing site. Your app and its database live on the Hetzner 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 Hetzner over AWS, GCP, and Azure.