When we started building small products, Vercel plus Supabase looked like the obvious stack.
It was a good way to get moving. The frontend deployed quickly. Postgres and auth were ready. We did not need to think about servers.
The app lived in one place. The database and auth lived in another. Redis, background jobs, logs, backups, domains and monitoring each added another service or another decision. Every service had its own dashboard, limits and billing model.
We were spending too much time answering questions that had nothing to do with the product: Which service owns this failure? Is this a networking issue, a database issue or a deploy issue? Which limit are we close to? What will the bill look like if traffic jumps? How do we reproduce the whole setup for the next project?
We wanted a Vercel + Supabase alternative built around a simpler unit: one machine, one stack and one bill.
A lot of "Vercel alternatives" content presents two choices: Stay on managed platforms. Rent a server and run everything yourself.
Pure SaaS is convenient, but your application can become a collection of separate services with separate pricing. DIY self-hosting gives you control and predictable server costs, but now you own the operating system, TLS, upgrades, backups, monitoring and recovery.
The model we wanted was managed infrastructure on a dedicated machine: the app runs there Postgres runs there auth runs there optional Redis, CouchDB and NATS run there the operational work is handled for us the monthly price is fixed
It feels closer to a self-hosted backend for a solo builder, without making that builder the on-call infrastructure team.
To be clear, Vercel and Supabase are good products. They are often the right answer, especially when speed of setup, a broad feature set or automatic scaling matters more than infrastructure shape.
A typical project starts clean: Vercel for the app Supabase for Postgres and auth
Then real product requirements arrive: a worker or scheduled job Redis for a queue or cache another service for email object storage monitoring a separate backup plan a place to run a long-lived process
The result is service sprawl. Each new piece adds credentials, networking, logs, limits and a bill to understand.
There is also a cognitive cost. When an app request is slow, you may need to trace it across the hosting platform, a database platform and a third-party service before you even know where to look.
We wanted the default debugging question to be simpler: what is happening on this machine?
The current stack includes: container app hosting Postgres 17 with PgBouncer and pgvector auth that works with Supabase auth clients Redis CouchDB NATS with JetStream TLS, monitoring, updates and backups
You can operate it through a web portal, a REST API or an MCP server. All three reach the same underlying operations, so you can use the interface that fits the job.
That last part matters to us. We increasingly build with coding agents, and an infrastructure product should not force an agent to click around a dashboard. The MCP server exposes roughly 65 administrative tools, so an agent can provision and operate the stack. Payment still stays with a person, and destructive actions require confirmation.