The Indie Hacker's Guide to Building on Open 2026

Open source can give a solo founder more control over product data and infrastructure, but it also transfers work that a managed service would otherwise perform. The practical question is not how many subscriptions can be replaced. It is which operational responsibility you can own without slowing product validation or creating a fragile service.

TL;DR verdict

PocketBase fits products that need a portable executable and compact application backend. Self-hosted Supabase fits applications that benefit from its multi-service Postgres platform and can support its operating burden. Treat Coolify as a deployment surface only after sizing the host for builds and workloads. Choose n8n when workflow automation justifies its infrastructure, maintenance, and edition boundaries. Keep every choice conditional: managed services can be appropriate when email deliverability, security, high availability, backups, or maintenance dominate.

Key takeaways

PocketBase can be deployed as a portable executable, but production still requires persistent data, backups, SMTP, rate limiting, reverse proxying, and superuser controls.
Self-hosted Supabase is a multi-service Docker deployment for a single project; the operator owns hardening, Postgres maintenance, high availability, backups, monitoring, and uptime.
Coolify's documented minimum is 2 CPU cores, 2GB RAM, and 30GB free storage; actual build and application capacity depends on workload.
n8n Community Edition is free to self-host, but operator responsibility remains and some features require paid editions.
Replace fixed stack prices and revenue thresholds with a reader-supplied total-cost worksheet.
Operational responsibility is a product constraint. Choose managed services when the work they absorb matters more than infrastructure control.

At-a-glance table

Foundation	What current evidence supports	Operator responsibility	Good evaluation question
PocketBase	Portable single-executable deployment and built-in application services	Persistent data, backup and restore, SMTP, rate limiting, reverse proxy, superuser controls	Can one recover the product and its data on a fresh host?
Supabase self-hosting	Multi-service Docker deployment for a single project	Security, Postgres, high availability, backups, monitoring, maintenance, uptime	Does the product need the platform enough to justify operating it?
Coolify	Self-hosted installation with documented minimum resources	Host security, capacity, storage, builds, applications, upgrades	Can the host absorb peak build and runtime demand?
n8n self-hosting	Free Community Edition and cloud/self-hosted deployment choices	Infrastructure, maintenance, credentials, workflow recovery, paid feature checks	Which workflows are important enough to own?

Start with one foundation

An indie stack becomes risky when every interesting project is deployed before users need it. Begin with the application and one operating surface. Add analytics, support, automation, or identity only when the product requires it and someone can maintain it.

PocketBase as a compact product backend

Use PocketBase as a portable single-executable option, while documenting persistent data, backups, SMTP, rate limiting, reverse proxy, and superuser controls. Its production guidance also notes that there is no official Docker image, so a container image should not be mistaken for project-owned production guidance.

A client can still use a simple endpoint:

const pb = new PocketBase('https://api.yourapp.com')
const posts = await pb.collection('posts').getList(1, 20)

The small interface does not remove backend design. Authentication rules, authorization, validation, migrations, failure handling, and recovery remain application work.

Supabase when the platform earns its operations cost

Self-hosted Supabase is a multi-service Docker deployment for a single project; the operator owns hardening, Postgres maintenance, HA, backups, monitoring, and uptime. The local CLI stack is not a production-hardened substitute for that operating model.

Self-hosted Supabase can make sense when Postgres, authentication, storage, and realtime features materially reduce application work. It is not infrastructure-free. Map every service, secret, persistent volume, backup, health signal, and upgrade dependency before placing customer data on it.

Coolify as the deployment surface

Coolify’s current documented minimum is 2 CPU cores, 2GB RAM, and 30GB free storage; actual application/build capacity depends on workload. The installation guide also defines supported operating systems and architectures and calls for resource monitoring during builds.

Use the current official installation guide rather than a copied command. The existing installer destination remains Coolify's official install script, but confirm the supported platform and instructions at decision time.

n8n as an automation layer

n8n Community is free to self-host, but infrastructure and maintenance are the operator’s responsibility and some features require paid editions. An automation that labels "paying users," sends onboarding messages, or updates a CRM becomes production logic: credentials expire, schemas change, jobs fail, and workflow versions need review.

Workflow backups, credential rotation, failure queues, alerting, and paid feature dependencies are part of the product. The software edition may be free while the service still consumes capacity and maintenance time.

Hosted vs self-hosted

Decision	Managed service	Self-hosted option
Initial setup	Vendor account and application configuration	Host, network, secrets, storage, and service configuration
Security	Shared with vendor under its service model	Your team owns host and application hardening
High availability	Plan and vendor architecture determine it	You design, test, and operate it
Backups	Vendor controls and export paths apply	You schedule backups and prove restores
Email deliverability	Managed provider can absorb reputation and queue work	Self-hosting can add DNS, reputation, and delivery operations
Feature access	Plan limits apply	Community and paid editions can differ
Maintenance	Vendor maintains the service	You review upgrades, incidents, and capacity

License and open-source status

Open source does not mean every hosted or enterprise feature is included. Review the exact repository and edition for each product. The approved evidence in this guide focuses on deployment responsibilities, not a complete license analysis of every tool an indie founder might use.

For n8n, distinguish the free self-hosted Community Edition from features that require paid editions. For Supabase, distinguish the self-hosted single-project stack from the managed product. For any authentication or secrets layer, review the exact license and operating model before adoption.

Maintenance burden

The phrase "I'll set up backups later." is a warning sign, not a plan. Before launch, record:

where application and database state lives;
how backups are created, retained, encrypted, and restored;
who reviews updates and security notices;
how TLS, secrets, SMTP, and privileged accounts are managed;
which health checks and logs prove the service is working;
what happens when a deploy or workflow fails;
how to move back to a managed service or a prior version.

Do not estimate this work from a generic stack. Track the incidents, updates, and restore tests generated by your own workload.

Migration checklist

Name the user need and the current managed or manual workflow.
Confirm the exact open-source, community, hosted, or paid edition that meets it.
Build a disposable evaluation with representative data.
Document persistent state, secrets, SMTP, network exposure, and privileged users.
Create backups and complete a restore on a fresh environment.
Test upgrades, rollback, alerts, and failure behavior.
Run the old and new paths in parallel when practical.
Record actual infrastructure and maintenance costs before expanding the stack.

Deployment model table

Model	When it can fit	What must be explicit
Managed service	Validation speed or specialist operations matter most	Plan, portability, data handling, and exit path
Portable application binary	A compact service such as PocketBase fits the domain	Persistence, backup, proxy, SMTP, rate limiting, administration
Multi-service application platform	Supabase features justify the operating surface	Project boundary, database operations, HA, backups, monitoring
Self-hosted deployment platform	Several applications need a common deployment layer	Host capacity, build isolation, storage, networking, upgrades
Workflow automation service	Repeated integrations justify a runtime	Credentials, retries, alerting, versioning, paid feature boundaries

Source-backed evidence

PocketBase

The production guide supports portable deployment and identifies persistent data, backup/restore, SMTP, rate limiting, reverse proxy, and superuser controls.

Supabase

The self-hosting guide supports Docker for one project and assigns security, Postgres, high availability, backups, monitoring, maintenance, and uptime to the operator.

Coolify

The installation guide supports the 2 CPU cores, 2GB RAM, and 30GB free-storage minimum and says actual build and application capacity must be monitored.

n8n

The deployment-choice guide supports a free self-hosted Community Edition, operator-owned infrastructure and maintenance, and paid feature boundaries.

A reader-supplied TCO worksheet

Replace a fixed "cheap stack" total with your own inputs:

Cost or risk	Reader input
Hosting, storage, backup, and egress	Current provider quote for the intended workload
Maintenance	Expected owner hours multiplied by an internal rate
Migration	Export, import, testing, parallel run, and rollback work
Reliability	Required availability, recovery time, and recovery point
Managed alternative	Current plan price and included operational work
Exit cost	Data portability and time to move to another option

Use the result as a decision aid, not a universal revenue threshold. Keep product choices conditional: managed services can be appropriate where email deliverability, security, HA, backups, or maintenance dominate.

Methodology

OSSAlt reviewed four current primary sources on 2026-08-21: PocketBase production guidance, Supabase self-hosting documentation, Coolify installation requirements, and n8n deployment-choice documentation. The rewrite prunes unverified products and removes fixed provider prices, setup times, server-capacity claims, revenue thresholds, and runway arithmetic.

PocketBase going to production — accessed 2026-08-21
Supabase self-hosting — accessed 2026-08-21
Coolify installation — accessed 2026-08-21
Choose how to use n8n — accessed 2026-08-21

For adjacent product analytics, evaluate PostHog against its current hosted and self-hosted boundaries rather than assuming it belongs on the same host.

Find open-source tools for an indie stack at OSSAlt.