Self-hosting apps means running software on infrastructure you control instead of relying on a vendor to operate the entire application for you. For developers and small teams, a cloud VM is often the practical middle ground: you keep root access, Docker support, persistent storage, private networking, and deployment control without buying physical servers.
Raff Technologies can provide that infrastructure foundation through cloud VMs and related storage/networking services. The trade-off is important: self-hosting gives you more control, but your team becomes responsible for deployment, updates, security, monitoring, backups, and recovery.
This guide is for teams deciding what to self-host, how to size a self-hosting server, when Docker hosting on a VM makes sense, and when a managed platform is still the better choice.
Self-hosting apps at a glance
| Question | Practical answer |
|---|---|
| Best reason to self-host | You need control over runtime, data, deployment, networking, or cost structure |
| Best starting infrastructure | One Linux cloud VM for a lightweight app |
| Common deployment model | Docker Compose or a directly managed application service |
| Biggest hidden cost | Operator time: patching, monitoring, backups, upgrades, incidents |
| Biggest avoidable risk | Hosting important data without a tested restore path |
| When to use managed hosting | When reducing operational responsibility matters more than infrastructure control |
| When to split services | When performance, security, recovery, or failure boundaries justify it |
Self-hosting is not automatically cheaper or more secure. It is an operating model. It works well when the control you gain is worth the responsibilities you take on.
What is self-hosting?
Self-hosting means deploying and operating software on infrastructure that you or your team administer. That infrastructure can be a machine in your office, a dedicated server, or—commonly for developers—a cloud VM.
A self-hosted application may include:
- an application process or containers;
- a database;
- persistent files or volumes;
- a reverse proxy;
- TLS certificates;
- DNS;
- monitoring;
- backups;
- secrets and configuration.
You do not need to build every component yourself. Docker images, package managers, Let's Encrypt, managed DNS, S3-compatible object storage, managed databases, and monitoring services can all be part of a self-hosted architecture.
The defining difference is that your team owns the operating environment and its lifecycle.
Why developers self-host apps
The strongest self-hosting use cases usually start with a requirement that a managed SaaS or PaaS does not satisfy cleanly.
Examples include:
- full OS or root access;
- Docker or Docker Compose control;
- custom ports or network services;
- private internal services;
- a specific runtime or package;
- persistent local/block storage;
- direct database administration;
- multiple apps on one server;
- custom backup and retention requirements;
- control over upgrade timing;
- a fixed server-resource model instead of usage- or seat-based billing.
A VM is especially useful when the application is already packaged for Linux or containers and your team is comfortable owning the server lifecycle.
The wrong reason to self-host is simply that open-source software has no license fee. Infrastructure and operations still have a cost.
Self-hosted apps vs managed platforms
Self-hosting and managed hosting optimize for different things.
| Factor | Self-hosted on a cloud VM | Managed platform/SaaS |
|---|---|---|
| Infrastructure control | High | Lower |
| Runtime flexibility | High | Platform-dependent |
| Server maintenance | Your responsibility | Mostly provider responsibility |
| Deployment abstraction | You choose/build it | Usually built in |
| Backup responsibility | You must define it | Varies by service |
| Scaling | You design it | Often partially automated |
| Debugging access | Full OS/application access | Platform-defined |
| Cost model | VM/storage/service resources | May include usage, seats, builds, add-ons |
| Best fit | Teams needing control | Teams prioritizing operational simplicity |
Choose a managed service when it solves the problem well and your team does not gain enough from operating the underlying system.
Choose self-hosting when infrastructure control is itself valuable.
Self-hosting server vs a server at home or in the office
Searches for a self-hosting server often mix two different models: owning hardware and administering your own software.
You can self-host software on a cloud VM without owning the physical server.
A home or office server gives hardware-level control but adds concerns such as:
- power and internet availability;
- router/NAT configuration;
- hardware replacement;
- physical security;
- off-site recovery;
- bandwidth and IP constraints.
A cloud VM removes most physical-hardware responsibility while preserving OS-level control. For internet-facing developer applications, that is often the simpler self-hosting model.
What apps can you self-host?
A wide range of software can run on a Linux VM when its documented requirements fit the server.
Common categories include:
| Category | Examples | Typical reason to self-host |
|---|---|---|
| App deployment | Coolify, Dokploy | Control the deployment layer |
| Automation | n8n, Node-RED | Run workflows under your own infrastructure account |
| CMS/publishing | Ghost, WordPress, Strapi | Runtime and data control |
| Analytics | Plausible, Umami, Matomo | Operate analytics yourself |
| Documentation | Outline, BookStack, Wiki.js | Private team knowledge base |
| Git/DevOps | Gitea, Forgejo, GitLab | Source-control and CI infrastructure |
| Monitoring | Uptime Kuma, Grafana, Prometheus | Internal observability and uptime monitoring |
| Collaboration | Mattermost, Zulip | Operate team collaboration software |
| Backend platforms | Supabase, Appwrite | Self-managed application backend components |
Always use the application's current official system requirements when sizing. The fact that an installer starts successfully does not prove that a configuration is suitable for production.
Docker hosting on a cloud VM
Docker hosting has clear commercial search intent, but the decision is broader than installing Docker.
A cloud VM is a good Docker host when you want:
- direct control of Docker Engine;
- Docker Compose deployments;
- persistent volumes;
- custom networks;
- multiple containerized services;
- control over reverse proxies and TLS;
- SSH access for debugging;
- predictable server-level resource boundaries.
A simple architecture is:
Internet ↓ Reverse proxy / TLS ↓ Docker host ├─ App container ├─ Worker container └─ Supporting service ↓ Persistent storage / database / object storage
Docker reduces packaging and deployment inconsistency. It does not automatically provide backups, high availability, security, monitoring, or safe upgrades.
For persistent data choices, use Docker Volumes vs Bind Mounts.
Do you need Kubernetes for self-hosting?
Usually not at the beginning.
One VM with Docker Compose can be easier to operate than a cluster when:
- one server has enough capacity;
- brief maintenance windows are acceptable;
- a small team owns the workload;
- horizontal scheduling is not required;
- the app has only a few services.
Kubernetes becomes more relevant when container coordination, service count, scheduling, rollout requirements, or team scale justify the additional operating model.
Do not adopt Kubernetes simply because an application runs in containers. Use Kubernetes vs Docker Compose for Small Teams for that decision.
Choose a self-hosting architecture before choosing a VM size
Sizing should follow the architecture.
Ask:
- How much memory does the application require at idle and under load?
- Does it include a database?
- Are there background workers or build jobs?
- How much durable storage is needed?
- Will uploads grow independently of compute?
- What happens during backup, import, upgrade, or traffic spikes?
- How quickly can the service be restored if the VM is lost?
A lightweight internal tool may fit comfortably on a small VM. A database-heavy platform or build server may require much more memory, CPU, and storage headroom.
Avoid evergreen tables that pretend one fixed VM size is universally correct for a named application. Application requirements change, plugins and usage patterns differ, and production load matters more than the installer's minimum.
VM sizing principles for self-hosted apps
Use these workload signals instead:
| Workload signal | Resource to watch first |
|---|---|
| Several application processes/containers | RAM |
| Builds, transcoding, heavy automation | CPU |
| Database working set | RAM + storage latency |
| Large uploads/media | Storage capacity + object storage design |
| Many logs | Disk capacity + retention |
| High concurrent requests | CPU, memory, application/database latency |
| Background queues | Worker CPU/RAM + database/queue capacity |
Start with enough headroom to survive normal operational tasks—not merely enough resources to boot.
On Raff, compare current cloud VM options and pricing when you deploy rather than relying on an old price embedded in an evergreen guide.
The basic self-hosting stack
A production-aware self-hosting stack typically has these layers:
| Layer | Purpose |
|---|---|
| Linux VM | Compute and OS control |
| Docker Compose or service manager | Repeatable application execution |
| Reverse proxy | HTTP routing and TLS termination |
| DNS | Maps the domain to the public service |
| Host/network policy | Limits unnecessary exposure |
| Persistent storage | Keeps application state |
| Backup destination | Protects recoverable copies away from the active workload |
| Monitoring/alerts | Detects failures and capacity problems |
| Secrets management | Protects credentials and tokens |
The exact tools matter less than clear ownership of each layer.
Security checklist for self-hosted apps
Self-hosting gives your team administrative control, so security responsibilities become explicit.
At minimum:
- use strong SSH authentication and restrict administrative access where practical;
- keep the OS and application dependencies patched;
- expose only required public ports;
- use HTTPS for public web applications;
- do not expose databases or caches publicly without a specific, controlled requirement;
- keep secrets out of source repositories;
- use least-privilege application and administrator accounts;
- review application admin accounts and MFA support;
- monitor authentication failures and unusual activity;
- document who owns patching and security updates.
Use Cloud Firewall Rules Explained for inbound/outbound policy and Cloud Security Fundamentals for the wider security baseline.
Persistent data changes the self-hosting decision
A disposable application server is easy to replace. A server containing the only copy of customer data is not.
Map every piece of state:
- database records;
- uploaded files;
- application configuration;
- secrets;
- queues or jobs that must survive restart;
- certificates where relevant;
- generated business data.
Then decide which state belongs on:
- the VM's filesystem;
- an attached volume;
- a database;
- S3-compatible object storage;
- another managed service.
For durable objects and backup archives, Raff Object Storage provides an S3-compatible storage option. Verify current pricing and limits on the live product page before designing around them.
Backups are not the same as snapshots
A VM snapshot can be useful before an upgrade or infrastructure change, but important self-hosted applications should have a recovery plan at the application/data level as well.
A practical backup design answers:
- What data is backed up?
- How frequently?
- Where is the copy stored?
- How long is it retained?
- Are credentials/configuration included safely?
- How is database consistency handled?
- Who receives failure alerts?
- When was the last successful restore test?
A backup job completing successfully is not proof of recoverability. A restore test is stronger evidence.
Use Raff Data Protection and the current storage options according to the workload's recovery requirements.
When to separate the database
Running an application and database on one VM is a valid starting point for many small workloads.
Separate the database when you need an independent boundary for:
- recovery;
- backups;
- memory/storage tuning;
- access control;
- maintenance;
- scaling;
- application-server replacement.
At that point, a managed database may reduce operational work compared with operating the database yourself.
Raff's Managed Databases can be evaluated when database operations—not application control—are the burden you want to remove.
This is a useful hybrid model: self-host the application while buying management for the stateful component that is expensive to operate well.
Use private networking as the stack grows
A one-VM deployment may have very little internal networking. Once the database, workers, or supporting services move to separate systems, private connectivity becomes more valuable.
A common topology is:
Internet ↓ Public app/reverse proxy ↓ Application VM ↓ private network Database / worker / internal service
Raff VPC can provide supported private connectivity between Raff resources. Private networking reduces unnecessary public exposure but does not replace authentication, firewall policy, TLS requirements, or service permissions.
Self-hosting cost: calculate total operating cost
A cheap VM is not the total cost of self-hosting.
Include:
- VM compute;
- storage and backups;
- object storage if needed;
- database resources;
- monitoring/alerting;
- email or other external services;
- engineering time for upgrades;
- incident and recovery time.
A useful comparison is:
Self-hosted monthly infrastructure + expected operator time + recovery/maintenance overhead vs managed service subscription + usage/add-ons + platform constraints
This makes the self-hosting vs managed hosting decision more honest. Self-hosting can still be the better choice, but the reason should survive the full-cost comparison.
When not to self-host
Managed hosting is often the better choice when:
- nobody owns Linux/server operations;
- the service is critical but restore procedures are untested;
- the team cannot maintain patches and upgrades;
- compliance obligations exceed current operational capability;
- the managed alternative is inexpensive relative to engineering time;
- the workload requires availability architecture the team cannot operate;
- the software vendor does not support the self-hosted deployment model you plan to use.
The strongest infrastructure decision is sometimes to avoid operating another service.
A practical self-hosting migration path
Do not turn the first deployment into a platform project.
Stage 1 — One app, one VM
Deploy one useful application. Configure HTTPS, access, monitoring, and backups.
Stage 2 — Make deployment repeatable
Use Docker Compose, versioned configuration, or another reproducible deployment process.
Stage 3 — Separate durable data
Move important uploads or backup archives to suitable storage. Create application/database backup procedures.
Stage 4 — Separate operationally expensive state
Move the database to its own VM or a managed database when recovery, tuning, or maintenance justify it.
Stage 5 — Add private networking
Connect internal components through controlled private paths as the topology grows.
Stage 6 — Scale only the constrained role
Resize or separate the component that measurement shows is limiting performance or reliability.
Stage 7 — Consider orchestration
Evaluate Kubernetes only when the coordination problem is real.
How Raff fits a self-hosted application stack
Raff's role in self-hosting is to provide infrastructure building blocks while your team retains application control.
A practical Raff path can use:
- Raff VM or Linux VM for the application/Docker host;
- Raff VPC for supported private connectivity;
- Volumes when attached block storage fits the workload;
- Object Storage for suitable S3-compatible object workloads and backup archives;
- Managed Databases when you want to reduce database operations;
- Data Protection according to recovery requirements;
- Kubernetes when orchestration is actually justified.
This lets a small team begin with one VM and add infrastructure boundaries as the workload proves that it needs them.