The Self-Hosted SaaS Stack You Can Run on Your Own VPS

There was a time when launching a SaaS product meant collecting a long list of subscriptions.

And before you even had your first customer, you could already be paying for 8–10 different services.

But there is another way. What if your VPS could become your own small private cloud? That is exactly what I wanted to explore with a Hostinger VPS.

The goal isn’t to replace every cloud service just because self-hosting is possible. That’s a trap.

The real goal is more practical:

For this setup, the foundation is a Hostinger VPS running Docker and Coolify. Hostinger currently offers VPS configurations with options such as 8 GB and 16 GB RAM, which gives you room to build a serious self-hosted environment rather than just running a single application.

Here’s what that stack looks like.

Think of the VPS as your private mini-cloud:

The important part isn’t just the software, it’s the architecture.

GitHub becomes the source of truth, Coolify becomes the deployment layer and Docker isolates the services.

Your VPS becomes the infrastructure layer and external services are used selectively where self-hosting introduces unnecessary risk.

If there is one tool that makes this architecture practical, it is Coolify.

Without it, you are managing Docker containers, reverse proxies, SSL certificates, deployments and environment variables manually.

With it, your VPS starts feeling much more like a managed cloud platform.

Coolify supports GitHub-based automatic deployments through GitHub Apps, Actions or webhooks. This is the first major principle of the stack Your VPS should not require you to SSH into it every time you deploy.

You can create separate Coolify projects for your SaaS applications.

For example:

And each can point to its own GitHub repository.

Another advantage is that you don’t need to commit secrets into GitHub.

Everything can be configured through Coolify’s environment-variable management.

Coolify supports both runtime and build-time variables, and it also provides mechanisms for handling build secrets without embedding them into image layers.

For example:

Your repository contains the code. Coolify contains the deployment configuration and secrets.

That’s a much cleaner separation.

The database decision should depend on your application rather than forcing one technology everywhere.

If you’re building:

I’d generally start with PostgreSQL.

If your application naturally works with flexible documents and schema-less data, MongoDB can be a better fit.

The important distinction is authentication.

You can build:

Or use a backend platform that bundles authentication with the database.

For developers who don’t want to build authentication from scratch, self-hosted Supabase is an interesting option.

It gives you PostgreSQL together with authentication, APIs, storage and other backend capabilities.

The self-hosted version can be deployed using Docker, and Supabase officially recommends Docker for self-hosting.

That means you can have:

There is an important caveat.

Self-hosted Supabase is not the same operational experience as managed Supabase.

When you self-host, you become responsible for upgrades, security, backups, database maintenance, monitoring and disaster recovery.

Supabase currently lists 4 GB RAM as a minimum for its full self-hosted stack and recommends 8 GB or more for small-to-medium production workloads.

So don’t casually throw every service onto a tiny VPS.

Applications eventually need file storage.

Instead of depending entirely on a cloud object-storage provider, use RustFS that can run an S3-compatible object-storage layer on your VPS.

This gives your application an interface similar to:

The benefit is portability.

Your application talks to an S3-compatible API rather than being tightly coupled to a specific cloud vendor. For smaller workloads, this can be an attractive self-hosting strategy.

But remember Object storage is only useful if you also have a backup strategy.

Your VPS is not a backup.

Many SaaS applications eventually need search.

Users want to find:

A lightweight self-hosted search engine such as Meilisearch can handle this use case.

The architecture becomes:

Your application database remains the source of truth. The search engine becomes the optimized index. That separation is important.

Don’t treat your search index as your primary database.

Analytics is another area where self-hosting becomes interesting. A self-hosted analytics platform can give you visibility into:

One option from our finalized stack is PostHog, but this is where I would add a big warning.

PostHog is not a tiny Docker container you casually throw onto a 4 GB VPS.

Its architecture involves multiple components and can become resource-heavy, particularly around its analytics infrastructure.

So if you’re running a serious self-hosted analytics deployment, size the VPS accordingly.

This is exactly why I wouldn’t blindly recommend “Just put everything on one $5 VPS.”

Self-hosting is about economics and capacity planning.

Self-hosting introduces a problem that managed platforms normally hide You are now responsible for knowing when your infrastructure breaks.

That’s where Uptime Kuma fits nicely.

You can monitor:

It supports HTTP, TCP, DNS, Docker-container monitoring and notification integrations.

You don’t need a complicated monitoring platform just to answer “Is my application alive?”

For a small SaaS, simple monitoring can go surprisingly far.

Uptime monitoring answers “Is it running?” Observability answers “Why is it behaving like this?”

For that layer, SigNoz is part of the self-hosted stack.

You can use an open-source observability platform to centralize application telemetry and investigate problems without immediately adding another expensive SaaS subscription.

The ideal progression is:

This becomes increasingly important once your application has multiple services.

SaaS applications often contain repetitive workflows.

For example:

Instead of writing custom code for every workflow, you can use n8n as the automation layer.

Self-hosting automation gives you control over the workflows while keeping them close to the rest of your infrastructure.

This becomes especially useful when you’re connecting:

Your first version of a SaaS doesn’t need an elaborate product-feedback platform. But once users start requesting features, you need somewhere to collect and prioritize those requests.

Fider is a self-hostable feedback portal designed specifically for feature requests and suggestions.

Instead of receiving “Can you please add dark mode?” in five different emails, users can submit and vote on requests.

That creates a much better feedback loop.

Eventually, users will need help. That’s where Chatwoot fits into the stack.

It provides a self-hosted customer engagement/support platform and can centralize conversations across channels.

Your architecture can then look like:

For an early-stage SaaS, having customer support under your own infrastructure can be extremely useful.

As your stack grows, the number of secrets grows with it.

This is where Infisical can become part of the infrastructure.

The principle is simple Secrets should be treated as infrastructure, not configuration files sitting inside Git repositories.

Coolify already gives you environment-variable management, so you don’t necessarily need a dedicated secrets platform on day one.

Introduce this layer when the complexity justifies it.

Email.

This is where I would deliberately break the “self-host everything” philosophy. For transactional email, I would use Resend.

Why?

Because email reputation is not something I want to gamble with. You can technically self-host your mail infrastructure.

But then you have to worry about:

If your password-reset emails don’t arrive, your users don’t care that your infrastructure is beautifully self-hosted.

They just think “This SaaS is broken.”

For me, that’s not worth the risk Self-host infrastructure. Don’t self-host your credibility.

So the architecture I would build on a Hostinger VPS looks roughly like this:

This isn’t about blindly replacing every managed service.

It’s about choosing where ownership provides value.

Once everything is configured, the developer experience becomes surprisingly simple.

And you don’t have to SSH into the server every time. That’s the experience you want from self-hosting.

Self-hosting isn’t about avoiding every monthly bill, that’s the wrong metric.

The real question is Which parts of my SaaS infrastructure should I own, and which parts should I outsource because reliability is worth more than the savings?

For me, the answer looks like this:

But outsource the infrastructure where failure can directly damage customer trust.

Email is a perfect example and that’s the beauty of this architecture. You’re not trying to recreate AWS. You’re building something much more useful for a developer or small SaaS team a private cloud that you actually understand.

A Hostinger VPS + Docker + Coolify can become the foundation. GitHub becomes your source of truth. Your applications become containers. Your supporting services become independent workloads.

And your infrastructure becomes something you control rather than something you rent from ten different dashboards.

The cloud isn’t disappearing.

You’re simply bringing a surprisingly large part of it home.

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.