Why I Still Like Owning the Deployment Box

Deployment decisions have a strange way of looking simple until the product starts to matter.

At the beginning, the question is practical: where can I put this thing so people can use it? A static site can go to Cloudflare Pages, Netlify, or Vercel and be online quickly. A small API can live on Render, Railway, Fly.io, Azure App Service, Google Cloud Run, AWS App Runner, or a similar managed platform. For many projects, that is the right answer.

I use managed platforms too. This blog is an Astro site, and Cloudflare Pages fits it well. There is no database, no background worker, no object storage, no private network, and no special runtime expectation. Push to Git, build the site, serve the files close to users. That is the whole job.

The trade-off changes when the product becomes less like a website and more like a small business system.

A typical SaaS product may need PostgreSQL, Redis, file storage, scheduled jobs, background queues, email delivery, PDF generation, observability, backups, migrations, and a few internal services that are boring until they break. If the product touches compliance workflows, document processing, audit evidence, or AI-assisted review, the list grows. Deployment stops being a button and becomes part of the product architecture.

That is where I often lean toward owning the hosting layer, usually on a VPS or VDS.

This is not nostalgia. Running your own server is unfashionable enough that people sometimes talk about it like a guilty habit. But for the kind of systems I tend to build, it gives me a kind of control that is hard to replace.

Docker Compose is a big part of that.

With a Compose-based setup, I can run the application, PostgreSQL, Redis, MinIO, background workers, a reverse proxy, and supporting services in a way that is easy to inspect. Production can stay close enough to local development that debugging does not become archaeology. If I need another service, I can add it. If I need to inspect a volume, tune Postgres, move object storage, or run a one-off migration, I am working with Linux and containers instead of negotiating with a platform abstraction first.

That freedom matters more than it sounds.

Managed platforms are excellent when your needs fit their shape. Vercel and Netlify are very strong for frontend-heavy applications. Cloudflare Pages and Workers are excellent for static and edge-oriented workloads. Render and Railway make small web services pleasantly quick to deploy. Fly.io is interesting when running containers close to users matters. The large clouds can run almost anything if the team has enough patience and discipline.

The problem is that SaaS products rarely stay inside the original shape.

Today it is a web app and a database. Next month it needs a queue. Then larger uploads. Then a private admin worker. Then a long-running document parser. Then a service that should not be publicly exposed. Then the cheap simple setup becomes several paid add-ons, a few usage meters, and a deployment model spread across dashboards that each make sense in isolation.

At that point, the platform may still be good. It may even be the right choice. But the product is now being designed partly around someone else’s pricing model, limits, and roadmap.

The hyperscalers solve a different version of the problem. AWS, Azure, and Google Cloud are powerful, mature, and full of useful managed services. They are also very good at letting a small system grow an operational surface area that nobody wants to touch without a diagram and a quiet room. Larger teams can absorb that. A small team or solo founder can lose weeks to infrastructure decisions that have little to do with the product’s real risk.

There is also cost.

A single well-sized VPS can run a surprising amount of software, especially early in a product’s life. The invoice is understandable. Adding a worker, a cache, or S3-compatible storage does not immediately become a billing-design exercise. For something like my SaaS product AlturaQuantera, where the core needs are fairly concrete, backend APIs, document storage, background processing, database, and eventually AI-assisted review workflows, that predictability is useful.

Cost control is not only about spending less. It is about being able to think clearly.

When every feature has a hidden platform bill, product decisions get distorted. You may avoid useful architecture because the managed version costs too much. You may accept unnecessary complexity because the platform made it convenient. Owning the server does not make infrastructure free, but it does make the cost easier to see.

Vendor lock-in is another concern, although I think people sometimes talk about it too dramatically.

Every deployment choice creates some lock-in. A VPS locks you into your own scripts, backup strategy, and operational habits. A managed platform locks you into its runtime model, networking rules, database options, secrets, logs, deployment flow, and occasionally its idea of what your application should be.

The honest question is which lock-in you can live with.

For me, Docker, PostgreSQL, S3-compatible storage, and ordinary Linux servers are acceptable constraints. They are portable enough. They have decades of shared knowledge behind them. If a provider becomes expensive or unreliable, moving is annoying but understandable. That is a different risk from discovering that a product depends on a proprietary workflow that cannot be reproduced elsewhere without redesigning half the system.

The downsides of own hosting are real.

You own updates. You own firewall rules. You own monitoring. You own backups, and more importantly, restore testing. Disk usage, SSL certificates, security patches, failed services, log rotation, and boring availability checks all become your problem. A VPS is not cheap if the smaller invoice is paid for with constant low-grade anxiety.

There is also a skill tax. If the team does not understand Linux, Docker, networking, databases, and basic operational hygiene, managed hosting may be cheaper even when the monthly bill says otherwise. Infrastructure you do not understand becomes stress with an IP address.

So my preference is contextual.

For static sites, marketing pages, prototypes, and products that fit cleanly into a managed platform, I prefer the simple path. Cloudflare Pages for this blog is a good example. There is no virtue in operating machinery that does not need to exist.

For serious SaaS products with several moving parts, I like starting from a place where I can see the whole system. A VPS, Docker Compose, clear backups, restrained networking, and a small set of well-known services can carry a product a long way. Later, if the product earns the need for managed databases, regional deployments, Kubernetes, or cloud-native services, that decision can be made from evidence rather than fashion.

Deployment is not a moral choice. It is a trade-off.

Managed platforms buy convenience. Hyperscalers buy range. Own hosting buys control and clarity, if you are willing to pay with attention.

For the kind of software I care about, especially tools that need to survive real business workflows, attention is usually a better currency than magic.