Self-Hosting on One VPS: What to Run and What to Leave to SaaS

Choose ownership where it solves a specific problem

Start by naming the benefit you expect from running the application yourself. Keeping an internal tool close to your database is a concrete reason; installing an alternative because its dashboard looks familiar is weak justification. We favor self-hosting when it removes a recurring limitation that you can describe before opening a terminal.

Control means you decide when software changes and how long data stays available. It also means you own a failed upgrade when the maintainer's instructions do not match your installation. SaaS transfers much of that application maintenance to a supplier, while leaving you responsible for access permissions and your own recovery options.

For a small production setup, we would start with Ubuntu 24.04 LTS and a deliberately short service list. Share the host only among workloads that can tolerate failing together. Your marketing site and an internal dashboard may fit that boundary; the only copy of your recovery instructions does not.

Learning is also a valid return, provided you budget for it honestly. A hobby deployment can stop while you investigate a broken dependency, whereas a service used during customer work needs an owner who can respond. Decide which kind of commitment you are making before inviting other people to rely on it.

Put replaceable applications on the VPS first

Choose applications with understandable storage and an acceptable outage window. An internal wiki with regular exports is a better starting point than the login service required to reach every other system. The application should have documented installation and recovery procedures that you can follow without relying on an abandoned forum answer.

Treat file collaboration as an application with state, rather than a folder with a web interface. Nextcloud's recovery requirements include its database and relevant application directories alongside user files. Its official backup documentation explains the components and maintenance mode needed to avoid inconsistent backups.

Prefer an application whose useful data can leave in a documented format. Download an export before you commit, then inspect whether attachments and relationships survive. A container image makes installation portable, but your ability to move away depends on the stored data and the software that understands it.

Keep specialist services and recovery access outside

We would leave business email with a managed provider. Running a mailbox interface is only part of the job; sending reliable mail also involves reputation management and handling delivery failures. For a small team, that work usually has little connection to the reason you started operating a server.

Use a payment provider's hosted payment flow rather than collecting card details in your own application. You still need to protect account access and process payment events correctly. Keeping sensitive payment handling with a specialist reduces the operational scope you must understand before accepting money.

Keep the accounts needed to recover the VPS usable while the VPS is unavailable. Store provider recovery codes somewhere you can reach independently, and avoid making a self-hosted mailbox the only route to an account reset. Your domain registrar and backup storage need the same attention as SSH access.

Apply the same reasoning to monitoring. A local dashboard can explain resource pressure, but it cannot notify you after its own host disappears unless something elsewhere notices the silence. Use an external availability check, then choose local detail with the help of our monitoring tool comparison.

Budget for the work surrounding the application

Compare SaaS with the complete operating arrangement, rather than the VPS invoice alone. Your self-hosted application needs backup storage and somewhere temporary to perform recovery drills. Data transfer or a period of running old and replacement systems together may also affect the bill, depending on your provider.

The larger hidden cost is interrupted attention. An ordinary update can require reading migration notes and arranging a maintenance window before you discover an incompatible extension. If the person doing that work is also responsible for shipping the product, the operational task competes directly with customer work.

Write an operating allowance into the decision: reserve time for routine maintenance and separately allow for incident recovery. Include the effort of teaching another person to operate the service. An installation that only its original author understands creates a dependency that becomes visible during illness or time away.

SaaS has hidden costs too, including export work and integrations that become expensive to replace. Check those limits before choosing it, especially if your workflow depends on a feature that has no portable equivalent. Compare both options using the same outage tolerance and recovery expectations, rather than assuming either purchase removes responsibility.

Keep the deployment small enough to understand

For a containerized application, we would usually choose Docker Compose on Ubuntu 24.04 LTS. Docker documents using Compose in production, including production configuration and service replacement. Compose gives you a readable deployment definition; you still need to decide how persistent data survives replacement.

Expose the public web application through a reverse proxy and keep its database private. Avoid publishing database or administrative ports just because the installation example does so. Docker's firewall documentation explains why published container traffic can bypass the host's ufw rules, so verify exposure from another machine.

Choose explicit application image references and schedule updates when you can observe the result. Avoid unattended application upgrades that can migrate a database while nobody is available to recover it. Read our Docker Compose production checklist before turning a successful installation into a service people depend on.

Keep operational overhead in the hosting decision too. Use our Docker hosting selection guide to assess the host, then leave resource headroom for maintenance activity. Building an application beside its production database can create contention, so move builds elsewhere if they disrupt the running service.

Prove recovery before moving important data

Define acceptable data loss and acceptable downtime in language your team understands. An internal reference tool may tolerate losing recent edits, while a booking system may require much closer recovery points. Those requirements determine the backup method and whether a single host is an appropriate home for the application.

Back up application state using the application's documented consistency procedure. Copying a live database directory with a file backup tool is not automatically a usable database backup. Use restic for suitable files and completed database backups, with an encrypted repository outside the VPS and credentials scoped to the work.

Restore onto an isolated replacement environment before importing irreplaceable data. Open restored attachments and confirm that a new record can be saved, rather than stopping when the container starts. Prevent the restored copy from sending real notifications or running production integrations while you verify it.

Keep repository decryption material available independently of the failed host. Protect backup history from deletion where the storage service supports it, because a compromised server may expose its backup credentials. Our VPS backup procedure covers the surrounding workflow; choose a backup frequency that matches the loss you agreed to tolerate.

Give Claude Code bounded operational tasks

We use Claude Code for much of the routine operational work, with permissions tied to the task. It can inspect logs and prepare a configuration change for review without receiving unrestricted authority over the machine. The useful saving comes from reducing investigation and editing effort while keeping the decision boundary explicit.

Begin with read access to the relevant service configuration and sanitized diagnostic output. If the task requires a restart, authorize that named service and specify the checks that follow it. Keep permission changes and destructive database operations behind explicit approval, rather than allowing a broad request to repair anything it encounters.

Keep production secrets out of prompts and ordinary command output. Give the agent scoped credentials only when it needs them, and remember that access to the Docker daemon grants broad control over the host. A dedicated SSH account offers little protection if its other permissions let it become root indirectly.

Require an explanation of any state-changing command before execution, including the rollback assumptions. A previous container image may be easy to restore while its database schema is no longer compatible. Claude Code can help maintain the recovery notes, but you still own whether the proposed procedure preserves your data.

Move a low-risk service through a recovery rehearsal

Pick an internal service that can be unavailable without blocking customer work. Write down why you want to self-host it and what would make you return to SaaS. Keep its existing data source available during the pilot so the experiment does not force an immediate commitment.

1. Deploy the application with disposable data and record every persistent data location.
2. Configure external backups, then restore into an isolated replacement environment.
3. Perform a planned application update after reading its migration and recovery instructions.
4. Confirm that external monitoring reports an intentional application stop and its recovery.
5. Ask another operator to follow the written recovery procedure without relying on your memory.

Record where the rehearsal required undocumented knowledge, then fix those gaps before migration. If recovery takes longer than the outage you can accept, simplify the deployment or keep the managed service. Adding more applications to the host will not resolve an operating model that already exceeds your available attention.

Your next action is to choose that pilot application and write its recovery requirements before provisioning anything. Use the VPS deployment ladder to choose the deployment method that fits your experience. Move real data only after the rehearsal gives you evidence that you can operate the service.