Why StratoFusion moved production to one VM

A recent video about a fully self-hosted business stack prompted me to look back at a journey StratoFusion had already completed.

We moved production from a collection of separate hosting and observability services to a Docker Compose stack on a single OVHcloud virtual machine. The change brought the application, database, transfer worker, scheduler, monitoring and backups into one runtime we could understand as a whole.

The lesson was not “self-host everything”. It was more useful than that:

Own the parts of the stack where control, visibility and simplicity create real value. Keep specialist services external when they still earn their place.

That distinction shaped both the migration and the system we run today.

What moved onto the VM

The production stack now includes:

• Caddy for HTTPS and routing;
• Next.js for the application and control plane;
• a containerised rclone worker for file transfers, backups and synchronisation;
• PostgreSQL for application data;
• Weaviate for the separately controlled AI Search capability;
• a cron service for scheduled work;
• Prometheus and Node Exporter for metrics collection;
• Grafana for operational dashboards;
• GlitchTip and Redis for error tracking;
• automated PostgreSQL backups with offsite copies.

These services share one deployment boundary, but they have not been collapsed into one process. Compose still gives each responsibility its own container, health checks, storage and resource policy.

That is an important part of the design. Consolidating infrastructure does not have to mean erasing boundaries inside the software.

What stayed external

Some dependencies remain outside the VM by design.

GitHub Actions builds the application and transfer-worker images. GitHub Container Registry stores those images, each identified by the exact Git commit from which it was built. Production deploys that immutable revision rather than rebuilding source code on the server.

Authentication, billing and cloud-provider APIs also remain specialist external services. StratoFusion still depends on Clerk, Stripe, Google Drive, Microsoft OneDrive and Dropbox at the boundaries where their managed platforms provide capabilities we should not reproduce casually.

This is a hybrid stack, not an ideological one.

Why consolidation made sense

Before the migration, a single customer workflow crossed several operational platforms. The application, database, transfer worker, logs, metrics and error reporting lived in different places. Each service was individually reasonable, but the combined system carried a coordination cost.

One place to understand production

The VM provides a coherent view of the runtime. Application and database readiness, worker health, queue capacity, CPU, memory, disk and monitoring coverage can all be observed together.

That does not eliminate external provider failures or rate limits. It does make StratoFusion's own part of an incident easier to see. An operator can distinguish a busy transfer queue from an unavailable worker, or missing monitoring data from genuinely idle infrastructure.

Fewer deployment boundaries

The application and transfer worker are released together as immutable images. The deployment pulls an exact commit, drains active transfer work when required, updates the Compose stack and then verifies health.

There are still careful release and rollback procedures, but fewer independent hosting platforms need to agree about which version is live.

Infrastructure that matches the workload

StratoFusion is not only a website. Long-running cloud-to-cloud transfers, recursive listings, scheduled backups and synchronisation jobs need a durable data plane that is independent of a browser session.

Running that worker beside the control plane provides explicit queue and resource limits. It also makes its capacity visible to the same monitoring stack used for the rest of production.

Simpler cost and ownership decisions

A collection of low-cost managed services can become expensive in money and attention when every additional boundary adds another dashboard, quota model, network path and recovery procedure.

The VM replaces several of those recurring dependencies with one capacity decision. More importantly, it makes responsibility clear: we operate the runtime, so we also own patching, backups, restore rehearsals, monitoring and incident response for it.

The lower bill is useful. The clearer ownership model is the bigger architectural benefit.

A single VM is not free simplicity

Consolidation trades distributed-service complexity for operational responsibility.

One VM is also one failure domain. A poor deployment can affect several services at once. A full disk can threaten the application, database and monitoring stack. Backups that have never been restored are only a comforting theory.

The design therefore needs safeguards that a managed platform might otherwise provide:

• automated database backups and offsite copies;
• health checks for independent services;
• host and worker metrics;
• immutable image tags and identifiable releases;
• controlled deployments that account for active transfers;
• documented recovery procedures;
• explicit limits on what the web application is allowed to control.

The last point matters. StratoFusion's administrator dashboard can observe production health, but the application does not receive a Docker socket, SSH key or VM power controls. Moving services onto one host did not justify giving the customer-facing process authority over that host.

The old platforms are not the active architecture

The previous Vercel, Neon and Fly.io production resources are retained only as controlled recovery assets. They are not the authoritative runtime, and they are not safe standalone rollback targets after production data has moved forward on the VM.

That difference is recorded in the deployment model because ambiguous infrastructure is dangerous infrastructure. A retained resource should not quietly become a second production path.

The VM is authoritative. Recovery requires an explicit procedure and, where data is involved, reconciliation rather than a casual switch of DNS.

The decision is contextual, not permanent

A single Compose host is the right shape for StratoFusion now. It provides enough capacity, clearer observability and a release model that fits the team and workload.

It will not necessarily be the right shape forever.

The system keeps internal boundaries around the application, transfer worker, database, search infrastructure and monitoring so that a future change does not require rewriting the product. If capacity, availability requirements or team size change, one of those responsibilities can move behind the same stable interface.

That is the practical version of infrastructure ownership: choose the simplest responsible shape for the current system, preserve the boundaries needed for the next shape, and keep checking whether each dependency still earns its place.

Self-hosting was not the goal. A production stack we can see, explain and operate with confidence was.