Cloud, on-premise or hybrid: choosing where your systems run

Cloud, on-premise or hybrid is usually argued as a matter of principle. It is better treated as a set of requirements, because the hosting model matters far less than the operational questions underneath it. Here is the checklist we use with clients.

Start with the requirements, not the platform

• Data residency and compliance. Regulated clients often have the region, and sometimes the provider, decided for them.
• Connectivity. A warehouse or shop floor that must keep operating when the internet drops needs something running locally, whatever else you do.
• Background work. Invoicing runs, document generation and data syncs belong in workers, not web requests. If you need a queue, you need somewhere to run it.
• Real-time features. WebSockets and streaming change how you deploy and scale.
• Files and media. Uploads cannot live on an ephemeral container disk.
• Who operates it. The best platform is the one your team can debug at 3am.

The shapes that actually work

Platform as a service

Push a repository, get a database and a worker. The fastest path to production and the easiest to hand over. You pay for it in per-unit pricing and limited control over networking.

Containers on a single host

Docker Compose on one well-sized server, behind a reverse proxy that handles TLS. Cheap, predictable, easy to reason about, and adequate for a surprising amount of traffic. The trade-off is that you own patching and backups.

Managed containers

Containers without managing hosts, with autoscaling included. A good middle ground, provided you have moved sessions, cache and media off local disk.

On-premise or hybrid

Virtualised servers in your own rack, often with cloud used for backup, reporting or customer-facing services. The right answer when latency to machinery, data rules or existing investment say so. It needs the same discipline as cloud: infrastructure as code, monitoring, tested backups and a documented rebuild path.

Kubernetes

Worth it when you already run it, when several services share infrastructure, or when compliance demands the controls it provides. Adopting it for one application buys complexity you will pay for every week.

What we set up regardless of platform

1. Migrations and static assets handled as part of release, not by hand.
2. Static files cached properly; uploads on object storage or a backed-up volume.
3. A health endpoint the platform actually checks, that does not hammer the database.
4. Structured logs in one place with request ids, plus error tracking tagged by release.
5. Automated backups, and a restore someone has performed.
6. Secrets from a secret store, never from the repository.
7. A cache with a considered invalidation story.

One sharp edge worth naming

Full-page caching makes a content-heavy site fast and introduces exactly one trap: pages carrying per-visitor state. Forms, flash messages and anything behind a login must be excluded explicitly, and the cache must be cleared when content is published — otherwise editors report that "the site did not update" while you see the new version locally.

Pick the simplest platform that satisfies your constraints, then spend the time you saved on backups, monitoring and a release process.

Most teams do not need a more sophisticated platform. They need a boring one, wired up carefully, with someone who knows how to restore it.