Self-Hosting Without the SaaS Subscription

A SaaS subscription bundles software, hosting, maintenance, backups, support, and vendor margin into one convenient price. Self-hosting unbundles them. The software licence may cost nothing, but the running service still consumes infrastructure and human attention. Any credible comparison must include the whole system rather than placing a monthly invoice beside a zero.

Begin with an annual inventory. Record each tool's price, user count, important data, integrations, export path, and the consequence of an outage. Then estimate the self-hosted alternative: VPS capacity, backup storage in a different failure domain, domains, transactional email, monitoring, API usage, and realistic operator time. If two hours of specialist maintenance erase the saving, the calculation should say so.

The strongest candidates often have rising per-seat costs, stable workloads, well-maintained open-source communities, documented containers, and data that benefits from portability. Internal analytics, forms, knowledge tools, lightweight customer support, workflow automation, and development utilities can make sensible first migrations. Payroll, identity, payments, or a regulated system may deserve a managed provider until the organisation has deeper operating capability.

A migration fails early when the search begins with “find a clone of this brand.” Start with the job instead. Do you need product analytics, team chat, customer support, a form builder, a Git service, an internal database interface, or a deployment control plane? Once the operating requirement is explicit, several open-source approaches may become visible.

The Brownsmith Dynamics coding tools directory brings those options into one place. It includes deployment platforms such as Coolify and Dokploy; Git infrastructure such as Gitea; application backends such as Supabase and Appwrite; analytics choices including Umami and Plausible; internal-tool builders; content systems; customer-support tools; forms; email platforms; and other software that can run within infrastructure you control.

Treat the directory as a research starting point, not a promise that every project fits every business. Read the upstream licence and current installation guide. Check release activity, security reporting, data export, database support, architecture, backup instructions, resource needs, upgrade notes, and the health of the maintainer community. A popular repository can still be a poor match for a critical workload; a smaller focused project can be excellent when its scope aligns with the job.

A first self-hosted deployment does not need a fleet of servers. A supported Linux VPS, a domain, Docker, a Compose file, and an encrypted off-server backup can run a surprising amount of useful software. Coolify or Dokploy can add a friendlier control plane for Git deployments, environment values, domains, TLS certificates, logs, and repeatable releases.

The important thing is that every layer has a job. Git records the deployment definition and pins the version. Docker packages the application. Compose describes services, networks, volumes, and runtime configuration. A reverse proxy receives public web traffic and routes it to the correct internal port. DNS points the hostname to the server. Environment values configure the application without baking credentials into the image.

Ports deserve special attention because convenience can quietly become exposure. The application's internal port does not need to be the public port, and databases or queues should normally remain on a private container network. Publish only the web entry point the architecture requires. Administrative interfaces and staging systems can often remain private through Tailscale rather than accepting connections from the entire internet.

Private Model Infrastructure follows the same human-centred principle at a larger scale: automation should give people stronger, more governable capability rather than hide control inside a vendor boundary. Self-hosting is one expression of that principle. The human operator remains important because somebody must understand the system, approve change, investigate exceptions, and recover the service when assumptions meet reality.

Choose one open-source application with official Docker or Compose guidance and deploy it under a staging hostname. Import a representative copy of data, exercise the real workflow, and test the integrations people rely on. A successful home page is not evidence that an export imports correctly, email arrives, OAuth returns to the right callback, or uploaded files survive a container recreation.

Before changing production DNS, create an encrypted backup outside the VPS and restore it into a clean environment. Measure how much data could be lost between backups and how long restoration actually takes. Record the exact image version, configuration names, volume locations, DNS records, firewall rules, provider accounts, and recovery credentials. If this documentation exists only on the server being protected, it is not a recovery plan.

Run the old and new workflows in parallel where the data model permits it, or define a short and explicit cutover window where it does not. Freeze writes, take the final export, import, verify record counts and critical samples, then direct traffic. Keep the old service available until success criteria have been met and the rollback window closes.

The fragile version of self-hosting is a mystery server maintained by one enthusiastic person. It looks inexpensive until that person is unavailable, a credential expires, a disk fills, or an upgrade changes the database. The sustainable version has named ownership, observable health, a maintenance window, off-server documentation, access for a second authorised operator, and a tested recovery procedure.

Automation should reduce the memory burden rather than remove human judgement. Scheduled backups, health checks, certificate renewal, update notifications, secret scanning, and deployment logs prevent routine responsibilities from being forgotten. Alerts should lead to a named response and a useful runbook; otherwise they merely create more noise.

The same standard applies to AI APIs and MCP services. Keep provider credentials on the server, limit tool permissions, record which data crosses the self-hosted boundary, apply spending and rate limits, and require human approval for consequential writes. Hosting the application yourself does not make an external model local, and allowing a model to select a tool does not authorise the action.

This is the broader benefit of ownership: not a retreat from useful services, but the ability to decide where each capability belongs. People gain more power when systems are inspectable, recoverable, and transferable. The barrier to entry falls because deployment becomes a documented practice rather than private intuition, while experienced operators retain the authority to review, improve, and intervene.