Self-Hosting Apps on Raff: A Complete Guide for Developers

Introduction

Self-hosting apps on Raff means running your own software on a Raff Technologies Linux VM instead of relying entirely on managed SaaS platforms. For developers, founders, and small teams, this gives you control over runtime versions, deployment workflows, data storage, background workers, private services, and monthly infrastructure costs.

Self-hosting is the practice of deploying and operating software on infrastructure you control. Instead of paying a vendor to host the entire application for you, you run the application on a virtual machine, container stack, or private server environment. That control matters when you need Docker, custom ports, persistent storage, private networking, full root access, or predictable server pricing.

This guide explains when self-hosting makes sense, what types of apps work well on Raff, how to choose the right VM size, what a practical self-hosting stack looks like, and when a managed platform is still the better choice. It is the pillar guide for the Self-Hosting on Raff cluster, which includes hands-on tutorials for Coolify, Supabase, Plausible, Ghost, Vaultwarden, Outline, Mattermost, and GitLab CE.

Many teams do not need Kubernetes, a full platform engineering team, or a hyperscale cloud account to run useful software. A properly secured Raff Linux VM with Docker, backups, object storage, firewall rules, and a static IP can host many internal tools, automation platforms, dashboards, documentation systems, and lightweight production applications.

What Is Self-Hosting?

Self-hosting is the act of running software on infrastructure you manage directly. In practice, that usually means renting a cloud server, installing the required runtime, deploying the application, configuring a domain, securing access, and maintaining backups.

A self-hosted application can be simple or complex. A small Ghost blog, Plausible Analytics instance, or Vaultwarden password manager may run comfortably on a single VM. A heavier application like Supabase, GitLab CE, or Mattermost may require more CPU, memory, storage planning, and backup discipline.

The important difference is ownership of the operating environment. With a managed SaaS product, the vendor controls the servers, runtime, scaling model, data location, and operational limits. With self-hosting, you control those choices yourself.

That control is useful when your application needs:

• a specific runtime version
• background workers
• custom ports
• persistent uploaded files
• private internal services
• direct database access
• predictable monthly infrastructure costs
• Docker Compose deployment
• application-level backups
• full access to configuration files

Self-hosting does not mean doing everything from scratch. You can still use Docker images, open-source packages, managed DNS, SSL automation, object storage, monitoring tools, and backup utilities. The difference is that you decide how those pieces fit together.

Why Developers and Small Teams Self-Host Apps

Developers and small teams self-host because managed platforms often become limiting once a project needs more control. A simple hosted tool is convenient at the beginning, but the limitations appear when you need custom deployments, private services, nonstandard runtime behavior, or cost predictability.

The common transition looks like this: you start with shared hosting or a managed app platform because it is fast, familiar, and easy. Then your project grows. You need a background worker. You want Docker. You need a database extension. You want to run a private analytics tool. You need access to logs and configuration. At that point, a real VM becomes more practical than a restricted hosting panel.

At Raff, this is one of the clearest customer patterns we see: people do not usually move to a VM because they want more complexity. They move because they need control that shared hosting and managed platforms do not give them.

Self-hosting works especially well for:

• developer tools
• internal dashboards
• automation platforms
• private AI tools
• analytics systems
• CMS and publishing platforms
• team wikis
• Git repositories
• small SaaS backends
• staging environments
• API services
• monitoring tools

The strongest reason to self-host is not always cost. Cost matters, but control is often the real reason. A self-hosted environment lets you decide when to upgrade, how to secure the app, where to store files, how to back up the database, and which services should communicate privately.

What You Can Self-Host on Raff

You can self-host many applications on Raff if they run on Linux, Docker, Docker Compose, or standard server runtimes such as Node.js, Python, PHP, Go, Ruby, or Java. Raff is especially suitable for applications that need a persistent server, static public IP address, SSH access, and predictable compute resources.

The best self-hosted apps usually fall into a few categories.

The easiest self-hosting path on Raff is Docker Compose. Docker Compose lets you define the application, database, volumes, ports, and environment variables in one file. It is simple enough for small teams but structured enough for repeatable deployments.

If you are new to this workflow, start with a simple Docker-based app before hosting heavier platforms. A good progression is:

1. Uptime Kuma or Plausible
2. Ghost or n8n
3. Coolify
4. Supabase or Mattermost
5. GitLab CE

This progression helps you learn the core operational skills before running heavier production systems.

Self-Hosting vs Managed Platforms

Self-hosting and managed platforms solve different problems. Self-hosting gives you control; managed platforms give you convenience. The right choice depends on whether your team values flexibility or reduced operational responsibility more.

A managed platform is often the right choice for teams that want to ship quickly without touching server operations. Render, Railway, Heroku-style platforms, Vercel, and Netlify reduce deployment work and hide server maintenance. That is valuable.

A VM is the better choice when you need more control than those platforms allow. If you want to run Docker Compose, expose custom services, host multiple internal tools, use private networking, manage your own database, or avoid usage-based pricing surprises, self-hosting becomes attractive.

The practical rule is simple: use managed platforms when convenience matters more than control; use a Raff VM when control, cost predictability, and operational flexibility matter more than abstraction.

Choosing the Right Raff VM Size

Choosing the right VM size depends on the application type, traffic level, memory usage, database size, and whether the app runs background workers. Most self-hosted applications fail from memory pressure before CPU pressure, so RAM is usually the first number to check.

Raff offers General Purpose VMs for flexible workloads and CPU-Optimized VMs for workloads that need dedicated, consistent compute. General Purpose VMs are a strong fit for websites, dashboards, test environments, and lightweight self-hosted tools. CPU-Optimized VMs are better for databases, build workloads, analytics engines, CI/CD, and heavier platforms.

Use this as a starting framework:

For early projects, start smaller and resize when usage justifies it. Raff supports resizing resources from the dashboard, so you do not need to overbuy for a project that has not proven its workload yet.

For production applications, avoid running every service on the smallest possible VM. A server that is technically “enough” at idle may struggle during builds, backups, imports, traffic spikes, or scheduled jobs. A little headroom is cheaper than debugging random out-of-memory crashes.

The Basic Self-Hosting Stack

A reliable self-hosting setup needs more than the application itself. The application is only one part of the system. You also need networking, security, backups, monitoring, and a deployment method.

A practical Raff self-hosting stack usually includes:

The key is to separate responsibilities. Your reverse proxy should handle traffic. Your app should run in a predictable environment. Your database should have backups. Uploaded files should not be treated casually. Secrets should not be committed to Git.

For many small teams, a single VM can run the entire stack at the beginning. That is normal. As the workload grows, you can separate the database, move uploaded files to object storage, add a second VM, or introduce private networking.

Security Checklist for Self-Hosted Apps

Self-hosting gives you control, but it also gives you responsibility. A self-hosted app should not be exposed to the internet without basic server hardening.

At minimum, every Raff self-hosted app should follow this checklist:

• use SSH keys instead of password-based SSH login
• keep the operating system updated
• expose only required ports
• enable a firewall
• run apps behind a reverse proxy
• use HTTPS for all public web apps
• store secrets outside the application repository
• use strong admin passwords
• enable application-level two-factor authentication when available
• back up databases and uploaded files
• test restores before you need them
• monitor disk usage and memory usage
• review logs after failed logins or suspicious behavior

The most common mistake is exposing too much. Most self-hosted applications only need ports 80 and 443 open publicly after setup. SSH should be restricted, protected with keys, and ideally limited by IP if your workflow allows it. Databases should not be exposed publicly unless there is a specific reason and additional network restrictions are in place.

Raff provides infrastructure-level security features such as firewall controls, SSH-based access, DDoS protection, and isolated VM environments. But application security is still shared responsibility. Raff can provide the server foundation; you still need to configure the software correctly.

Backup and Recovery Planning

Backups are not optional for self-hosted apps. If an app contains users, content, uploads, analytics, secrets, configuration, or business data, it needs a backup plan before it becomes important.

A good self-hosting backup plan protects four things:

1. the database
2. uploaded files
3. configuration files
4. secrets and environment variables

VM snapshots are useful, but they are not a complete backup strategy by themselves. A snapshot captures server state at a point in time, which is helpful before upgrades or risky changes. But application-level backups are still important because they let you restore a database, move an app, or recover specific files without restoring the entire VM.

For self-hosted apps on Raff, a strong backup pattern is:

• scheduled database dumps
• compressed application configuration backups
• off-server storage for backup archives
• periodic VM snapshots before major upgrades
• restore testing every few months

Raff Object Storage is a natural fit for backup archives because it is S3-compatible and designed for backups, media files, logs, and static assets. Raff Object Storage starts at $7/month with 100 GB storage, 1 TB egress, unlimited API requests, and the S3 endpoint s3.raffusercloud.com.

The simplest rule is this: if losing the app tomorrow would be painful, create a restore plan today.

When You Should Not Self-Host

Self-hosting is powerful, but it is not always the right choice. You should not self-host just because the software is open source or because the monthly price looks cheaper.

Avoid self-hosting when:

• your team has no one comfortable with Linux basics
• the app is mission-critical but no one can maintain it
• compliance requirements exceed your operational maturity
• you cannot commit to patching and backups
• you need global edge deployment immediately
• a managed product is cheaper than your team’s maintenance time
• downtime would be unacceptable and you have no redundancy plan

A managed platform may be better for teams that want to focus entirely on product development. For example, a startup with no infrastructure experience may choose managed database hosting, hosted analytics, or a managed PaaS until the team has time to operate its own stack.

The honest answer is that self-hosting trades vendor dependency for operational responsibility. That trade can be excellent, but only when you understand what you are taking on.

Raff-Specific Context

Raff is well suited for self-hosting because it gives developers the infrastructure primitives they need without forcing them into a complicated cloud architecture. You can start with a Linux VM, install Docker, attach storage, configure a firewall, assign a static IP, and deploy real applications without building an entire platform first.

For many developers, this is the useful middle ground between shared hosting and hyperscale cloud. Shared hosting is simple but restrictive. Hyperscale cloud is flexible but often complex. Raff gives you direct server control with predictable VM plans, NVMe SSD storage, static public IPv4, DDoS protection, snapshots, backups, private networking, and S3-compatible object storage.

That combination matters for self-hosting because most apps need more than compute. A serious self-hosted setup eventually needs:

• a stable public endpoint
• secure SSH access
• firewall control
• persistent disk
• off-server backups
• optional object storage
• monitoring
• resize options
• human support when something goes wrong

Raff does not remove the need to understand your application. But it does provide a clean foundation for running it.

The most practical starting point for the Self-Hosting on Raff cluster is a General Purpose VM for lightweight tools and a CPU-Optimized VM for heavier workloads. For example, a small Vaultwarden or Uptime Kuma instance can run on a small VM, while Coolify, Supabase, Mattermost, and GitLab CE need more memory and storage headroom.

Recommended Self-Hosting Paths

The best self-hosting path depends on what you are trying to build. Do not start with the heaviest tool. Start with the simplest app that teaches the operational pattern you need.

Path 1: Beginner self-hosting

Start here if you are new to Linux servers.

This path teaches the core pattern: deploy, expose safely, persist data, back up, and monitor.

Path 2: Developer deployment platform

Start here if you want to deploy multiple apps from Git.

Coolify is a strong option when you want a platform-like workflow without giving up server control. It lets you self-host a deployment layer for apps and services while keeping the infrastructure under your own account.

Path 3: Internal team tools

Start here if you are building infrastructure for a small company.

This path is useful for teams that want control over collaboration tools, data location, and operating cost.

Path 4: Application backend

Start here if you are building a SaaS or app backend.

Supabase is powerful, but it is not the lightest starting point. Treat it as a real backend platform, not a tiny side project container.

Practical VM Sizing Examples

A realistic sizing plan prevents frustration. These recommendations are starting points, not permanent limits.

The safest strategy is to start with the smallest plan that gives the app comfortable headroom, then resize based on real CPU, RAM, disk, and network usage. Do not choose a tiny VM for a heavy platform just because the installer technically starts. Production reliability depends on headroom.

Cost Planning for Self-Hosted Apps

Self-hosting can reduce software costs, but the better reason to self-host is predictable control. A VM has a clear resource boundary. You know how much CPU, RAM, and disk you are paying for. That makes budgeting simpler than platforms where cost grows through seats, usage, builds, bandwidth, add-ons, or feature tiers.

When estimating self-hosting cost, include:

• VM monthly cost
• block storage or extra disk
• object storage for backups and files
• domain name
• email provider if the app sends email
• monitoring or alerting tools
• your team’s maintenance time

For small apps, the VM may be the main cost. For production apps, storage, backups, and operations matter too.

A practical cost model is:

Self-hosting is not “free software on a cheap server.” It is controlled infrastructure. Treat it that way and it becomes reliable.

Common Self-Hosting Mistakes

Most self-hosting problems come from weak operations, not bad software. The app may be well built, but the deployment environment is often rushed.

Avoid these common mistakes:

• running everything as root without understanding permissions
• skipping firewall configuration
• exposing databases to the public internet
• storing secrets in Git
• relying only on VM snapshots
• never testing backups
• ignoring disk usage
• installing many apps on one tiny VM
• skipping updates for months
• using default admin passwords
• forgetting email deliverability for apps that send notifications

The most dangerous mistake is having backups that have never been restored. A backup is only proven when you can restore it into a working application.

Another common issue is overloading one VM. It is fine to run multiple small apps on one server, especially for internal tools. But if one app grows or becomes critical, separate it. The cost of a second VM is often lower than the cost of debugging noisy-neighbor problems inside your own stack.

Content Cluster: What to Read Next

This guide is the pillar article for the Self-Hosting on Raff cluster. The next articles in the cluster should help you move from planning to implementation.

Recommended next tutorials:

• Install Coolify on Ubuntu 24.04: Self-Hosted PaaS on Raff
• Self-Host Supabase on Ubuntu 24.04 with Docker Compose
• Self-Host Plausible Analytics on Ubuntu 24.04
• Deploy Ghost CMS on Ubuntu 24.04 with Nginx
• Deploy Vaultwarden on Ubuntu 24.04 with Docker Compose
• Deploy Outline Wiki on Ubuntu 24.04 with Docker Compose
• Deploy Mattermost on Ubuntu 24.04 with PostgreSQL
• Deploy GitLab CE on Ubuntu 24.04

If you are starting from zero, begin with Docker and a lightweight app. If you already know Docker Compose, Coolify is the strongest next step because it gives you a platform-style deployment workflow while still running on infrastructure you control.

Conclusion

Self-hosting apps on Raff is a practical path for developers and small teams that want more control than shared hosting or managed platforms provide. You can run real software on a Linux VM, use Docker Compose for repeatable deployments, secure the server with firewall rules and SSH keys, store files in object storage, and build a backup plan that matches your risk.

The right self-hosting setup starts simple. Choose one app, deploy it cleanly, secure it, back it up, and monitor it. Once that pattern is reliable, you can add more tools or split heavier workloads onto separate VMs.

Raff Technologies is a strong foundation for this workflow because it gives you the core building blocks self-hosted apps need: Linux VMs, root access, static IPs, NVMe SSD storage, Docker support, snapshots, backups, private networking, and S3-compatible object storage. Start with a Raff Linux VM, deploy one useful application, and build the cluster from there.

This guide was prepared as the pillar for Raff’s Self-Hosting on Raff content cluster. The next recommended article is the Coolify tutorial, because it turns a single Raff VM into a self-hosted deployment platform for multiple applications.