We wanted a Vercel + Supabase alternative without becoming full-time DevOps

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.

Then the project grew, and the stack stopped feeling simple.

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.

No single part was terrible. The problem was the sum of them.

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.

So the two of us built Lathe.

The real choice is not SaaS versus self-hosting

A lot of "Vercel alternatives" content presents two choices:

1. Stay on managed platforms.
2. Rent a server and run everything yourself.

That misses the middle.

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.

For a solo builder or small team, both can become distracting.

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.

Why Vercel + Supabase can turn into glue fatigue

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.

Our frustration was architectural, not ideological.

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?

What we built instead

Lathe puts your app, database and auth on one dedicated 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.

Lathe itself runs on Lathe. The site, portal and API are deployed through the same system customers use. If that path breaks, we feel it first.

The bill is deliberately boring

Lathe plans range from $15 to $89 per month.

The price is based on the machine size, not request count, database connections or monthly active users. A larger workload may need a larger plan, but growth does not produce a new metered line item for every part of the stack.

This does not mean a dedicated machine is always cheaper. A mostly idle project can fit comfortably inside generous free tiers elsewhere. A large application that needs horizontal scaling or high availability needs a different architecture.

The goal is predictability, not a universal "cheapest" claim.

For the projects we build, we would rather choose a machine size and know the monthly number in advance.

What you give up

A useful alternative article should say where the alternative is worse.

Lathe is not a fit if you need:

• a global edge runtime
• automatic horizontal scaling
• high availability or automatic failover
• read replicas
• point-in-time recovery
• a large enterprise support organization
• a broad serverless ecosystem

Each Lathe instance is one machine. That is the feature and the limit.

Backups run daily, seven are kept, and restore checks run monthly. That is appropriate for many small products, but it is not the right recovery model for every workload.

Support comes from two founders by email. We are builders solving a problem we have ourselves, not a large platform with a support department.

If your application needs multi-region failover or cannot tolerate the loss of the most recent day of writes, do not put it on this architecture.

Why not just install a self-hosted PaaS?

You can, and for some builders that is the better choice.

Tools such as Coolify and Dokku can give you a good application platform on a server you control. If you enjoy infrastructure work, want full root access or need to customize every layer, DIY self-hosting offers more control.

The hidden cost is that the server remains yours to operate.

You are responsible for upgrades, disk pressure, backup configuration, restore tests, monitoring, certificate issues and whatever happens at 2 AM. Database operations deserve particular care. A backup job that says "success" is not the same as a restore you have tested.

Lathe is for the builder who likes the economics and simplicity of one machine but does not want server maintenance to become part of the product roadmap.

A practical decision checklist

Vercel + Supabase is probably the better fit when:

• you want their specific developer experience and integrations
• free tiers matter more than predictable paid pricing
• you expect sudden scale and want the platform to absorb it
• you need features outside a basic app, Postgres and auth stack

DIY self-hosting is probably the better fit when:

• you want root access
• you are comfortable owning production operations
• you need deep customization
• infrastructure work is part of the fun or part of your team's job

A managed dedicated machine is worth considering when:

• you are a solo builder or small team
• your app fits on one machine
• you want app, database and auth close together
• you prefer one fixed bill to several usage-based bills
• you want standard Postgres credentials and a straightforward way out
• you want an API or MCP server for infrastructure automation

Start with one real project

We do not think anyone should migrate an important production application based on a comparison article.

Start with a side project or a staging environment. Deploy the app, connect Postgres, turn on auth and test the failure paths. Export the database with pg_dump so you know the exit path works too.

We published a complete Next.js guestbook guide that walks through the app, database and auth flow. There is also a detailed Supabase alternative page covering compatibility and tradeoffs.

Lathe has a 14-day trial with no card. If the one-machine model fits how you build, try it. If you need the scaling model or wider ecosystem of Vercel and Supabase, keep using them.

The point is not that every project should leave managed platforms.

The point is that solo builders should have an option between stitching together a growing list of services and becoming full-time DevOps.