DEV Community: Lathe

Lathe vs a self-managed VPS: the cost of the work around the server

Lathe — Tue, 22 Sep 2026 08:37:01 +0000

A self-managed VPS is the cheapest way to get a whole virtual machine. Postgres, Redis and a container runtime are free. If you already enjoy operating servers, a VPS can be the correct answer.

Lathe is not trying to beat the raw server price. It charges for the machine plus the repeatable work around it: provisioning, TLS, credentials, monitoring, patching, backups, restore checks and a control surface for an agent or a person.

A quotable comparison

Cost or task	Self-managed VPS	Lathe
Monthly infrastructure	Your provider's server, disk, snapshots and traffic charges	$15, $29, $49 or $89 flat
Initial setup	Install, harden, firewall, TLS, database, pooling, backups, monitoring	About five minutes to a running machine on average
App deployment	Build and maintain your own path	Apps engine and deployment jobs included
Postgres	Install, configure, patch and monitor	Postgres 17, TLS, SCRAM and PgBouncer included
Redis / queue	Install, secure, persist and back up	Redis 8, CouchDB 3 and NATS 2 optional at no added price
Backups	Design, schedule and store them	Daily, seven kept
Restore proof	Build and run the test yourself	Latest backup restored to a temporary machine and checked monthly
Certificates	Configure and renew	Managed TLS
Security updates	Track and schedule	Fixed weekly maintenance window
Failure response	You	Automatic recovery first, founder support when it does not recover
Root access	Yes	No

The table does not assign a fake hourly rate to the founder. Put in your own.

If setup takes six hours and steady operations take two hours a month, multiply those hours by what an uninterrupted product hour is worth to you. Add that to the VPS, snapshot, storage and traffic bill. If your time is effectively free and the work is enjoyable, DIY wins. If those hours displace customer work, the raw server price is not the total.

The work people forget to price

The first install is rarely the expensive part. The recurring list is:

patch the operating system and every data service;
renew and debug certificates;
watch disk, memory and connections;
rotate credentials without breaking the app;
verify that backups restore rather than only checking that a job exited zero;
respond when the machine stops answering;
document enough of it that the next change is safe.

A backup that has never been restored is a hope, not recovery evidence.

What Lathe does not buy

Lathe is one managed machine, not an HA platform. It has no root or SSH for customers, no automatic failover, no horizontal scaling, no read replicas and no point-in-time recovery. A workload that needs those things should use a different architecture, whether managed or self-built.

It also does not make a very small VPS economically irrational. If you can run the stack safely for a few dollars and want the control, keep doing it.

A fair decision rule

Choose a VPS when root access, custom system packages and maximum control matter, and someone genuinely owns operations.

Choose Lathe when the app fits on one machine, standard containers and protocols are enough, and the person building the product should not also be the on-call infrastructure team.

The exit is ordinary: deploy the same container elsewhere, use pg_dump and pg_restore, and move the connection string. Test that exit before production. A managed service is easier to trust when leaving it is boring.

Read the canonical guide on Lathe

A Render alternative when you want one machine instead of a service stack

Lathe — Tue, 22 Sep 2026 08:36:19 +0000

Render gives an app team a conventional managed platform: web services, private services, workers, Postgres, a Redis-compatible Key Value service, cron jobs, static sites and more. Each part can have its own size and lifecycle.

Lathe takes the opposite shape. The app, database, auth and optional cache share one dedicated machine. That reduces the number of products and bills, but also removes the independent scaling and high-availability options that make Render useful.

Prices below were checked against Render's official pricing on September 22, 2026.

A small paid stack is a sum

Render currently lists a Starter web service at $7 a month, Basic Postgres with 256 MB at $6 a month, and persistent Key Value with 256 MB at $10 a month. That smallest paid app + Postgres + persistent cache example is $23 a month before extra database storage, a larger service or a paid workspace plan.

A more production-shaped Standard web service is $25 a month. Basic Postgres with 1 GB is $19. Persistent Key Value with 1 GB is $32. That example totals $76 a month.

These are not equivalent performance comparisons. They show the shape of the invoice: each service has a separate size and price.

Stack component	Render entry example	Lathe
Web service	Starter $7/month	Included on the machine
Postgres	Basic 256 MB $6/month	Included on the machine
Persistent cache	Key Value 256 MB $10/month	Redis included on the machine
Database storage	1 GB included, then $0.30/GB	Machine disk included
Persistent app disk	$0.25/GB/month	Machine disk included
Team/platform plan	Hobby $0; Pro $25 plus compute	No seat fee

What Render buys you

Render supports horizontal autoscaling on paid workspace tiers, service-by-service compute sizes, read replicas and high-availability options for databases, previews and a global CDN. A system that needs those capabilities should not be compressed into one machine to make the invoice prettier.

Render's free web service and 30-day free Postgres are also better for a disposable prototype where $0 matters more than always-on behavior.

What Lathe changes

Lathe plans cost $15, $29, $49 or $89 a month. The number changes only when you choose a larger machine. Apps, Postgres, Auth, Redis, CouchDB and NATS can run together. Database connections, auth users, requests, backups and up to 20 TB of outbound traffic do not become separate invoice lines.

The machine is dedicated to one customer, but it is not dedicated physical hardware. Its RAM, disk and failure boundary belong to the one account.

That last part is both the advantage and the limit. There is no automatic horizontal scaling, high availability, automatic failover, read replica or point-in-time recovery. Daily backups keep seven copies and are checked through scheduled restores.

Which one fits

Use Render when the parts of the system should scale and fail independently, when previews and managed platform breadth matter, or when you need the availability features of its larger database plans.

Consider Lathe when one small product fits on one machine, you want the app and data close together, and you prefer selecting a capacity tier to adding the prices of several services.

Start with a staging project. Render and Lathe expose standard containers and Postgres credentials, so the honest test is to run the same workload and compare the operations, not only the first number on each pricing page.

Read the canonical guide on Lathe

A Railway alternative when you want one machine and one number

Lathe — Tue, 22 Sep 2026 08:20:45 +0000

Railway is good at turning a repository into a running service. It supports private networking, volumes, replicas, preview environments and a broad range of workloads. If per-second resource billing fits how you operate, it can be the right choice.

Lathe is for a narrower case: a solo builder or small team whose app, database and auth fit on one machine and who would rather choose one monthly number than meter every running service.

Prices below were checked against Railway's official pricing on September 22, 2026.

The billing model is the main difference

Railway's Hobby plan is $5 a month with $5 of usage included. Pro is $20 a month with $20 included. Running services are metered per second. Railway currently lists memory at about $10 per GB per month, CPU at about $20 per vCPU per month, volumes at $0.15 per GB per month and service egress at $0.05 per GB.

That model is flexible: stopped services stop costing CPU and memory, and small workloads can stay near the plan minimum. It also means the final bill depends on the resources each service holds and uses.

Lathe plans are $15, $29, $49 and $89 a month. The price is for one machine. Apps, Postgres, Auth, Redis, CouchDB and NATS can share it, with storage, backups and 20 TB of outbound traffic included. There is no extra line for a second service, a database connection, an auth user or a request.

Question	Railway	Lathe
Monthly model	Plan minimum plus metered resources	One fixed machine price
App and data layout	Separate services joined by private networking	App and engines on one machine
Scaling	Replicas and high per-service ceilings	Upsize one machine; no horizontal scaling
Storage	Volumes billed per GB	Machine disk included
Egress	$0.05 per GB for services	20 TB included
Operations	Managed service platform	Managed machine with a narrower product

When Railway is the better fit

Choose Railway when you want replicas, ephemeral environments, services that scale or sleep independently, or workloads too large or too varied for one machine. Its free and low-minimum plans are also better for experiments that use almost nothing.

Railway is a platform for composing services. Lathe deliberately is not.

When one machine is simpler

A small app often needs one web process, Postgres, authentication and perhaps Redis. On Railway those are distinct resources, which is useful when each must scale alone. On Lathe they share a capacity budget and one failure boundary, which is simpler when the whole product is small enough to fit.

The trade is explicit. One machine means no high availability, no automatic failover, no horizontal scaling and no point-in-time recovery. Backups run daily and seven are kept. Support comes from two founders by email.

Use a real month, not a slogan

Railway publishes clear rates and usage controls. Take the CPU, memory, volume and egress from an actual month and calculate that total. Compare it with the Lathe machine size the same workload needs.

If independently scalable services and replicas are worth the metering, use Railway. If the product fits on one machine and the goal is one app, one database, one auth service and one bill, Lathe is the alternative.

Lathe has a 14-day Mini trial with no card. Test a staging workload, not an important production system, and keep the option that matches the architecture you actually need.

Read the canonical guide on Lathe

Give your AI agent a machine, not another dashboard

Lathe — Tue, 22 Sep 2026 08:19:47 +0000

A coding agent can write the application. It should also be able to create the place where the application runs, turn on Postgres, deploy the container and hand the app the right connection string.

Lathe exposes the same account through the portal, REST API and a remote MCP server at https://mcp.lathe.live. Connect it once, then Claude Code, Cursor or ChatGPT can inspect the live contract and do the infrastructure work in the same conversation as the code.

This guide uses the current production endpoint. An API key acts as you across the account, so give it only to an agent you would trust with the portal. OAuth is safer where the client supports it because you can disconnect that client separately.

Claude Code

Claude Code can sign in with OAuth. Run:

claude mcp add --transport http lathe https://mcp.lathe.live

Then open /mcp in Claude Code and finish the browser sign-in. If you prefer a static key from the Lathe Access page:

claude mcp add --transport http lathe https://mcp.lathe.live --header "Authorization: Bearer lathe_…"

Cursor

Create .cursor/mcp.json in the project for a project-scoped connection, or use Cursor's global MCP settings:

{"mcpServers":{"lathe":{"url":"https://mcp.lathe.live","headers":{"Authorization":"Bearer lathe_…"}}}}

Keep the real key out of Git. A user-level config or an environment-variable substitution is better than committing it to the repository.

ChatGPT

In ChatGPT web, open Settings, then Apps and Connectors, Advanced settings, and turn on Developer mode. Create an app for a remote MCP server, name it Lathe, enter https://mcp.lathe.live, and use OAuth. ChatGPT will send you to Lathe to sign in and approve the connection.

OpenAI's developer-mode documentation says write tools require confirmation by default. Keep that on. Creating or deleting infrastructure should never look like a read.

What to ask the agent

Start by making it read the live contract instead of guessing from this article:

"Use Lathe's list_plans tool and show me the current plans, regions and engine memory minimums."
"Use app_guide to check the container contract for this deployment."
"Create a Mini instance with Apps, Postgres and Auth, then give me the checkout or trial link."
"Add this repository as an app, set the health path and deploy the current image."
"Create a Postgres database for the app and issue short-lived connection credentials."

A paid instance is never silently purchased by the agent. The tool returns a checkout URL for a person to open. A new account can start one Mini trial for 14 days with no card.

The useful end state

The agent can get from a repository to:

a running machine with the engines the project needs;
an app deployment with its health path and domain;
a Postgres database owned by a normal role;
temporary connection credentials or the standard connection string;
job status, logs and a clean failure if provisioning or deployment did not finish.

The same controls apply as in the portal. Destructive tools require the instance id as confirmation. Connection access can be time-bounded and revoked. The agent does not receive a special back door.

What this is not

An MCP connection does not make an agent infallible. It gives the agent current tools and current facts. Review the plan, region and engines before opening checkout. Keep production deletion confirmations enabled. Disconnect a client or revoke its key when the work is done.

The payoff is smaller than "autonomous DevOps" and more useful: the agent that changed the code can also read the actual deployment contract, make the matching infrastructure change and report the job that proves it happened.

Read the canonical guide on Lathe

What Vercel + Supabase really costs when your app gets traffic

Lathe — Mon, 21 Sep 2026 04:01:32 +0000

What Vercel + Supabase really costs when your app gets traffic

When we started building small products, Vercel plus Supabase looked inexpensive.

It often is at the beginning. Both products have useful free tiers. A small app can run for months without a meaningful infrastructure bill.

Then the app gets actual traffic, another person joins the project, or a customer asks for a feature that sits outside the included quotas.

The bill does not suddenly become bad. It becomes harder to predict.

The two of us kept coming back to the same questions:

What is the minimum paid bill for the whole stack?
Which usage is included, and which usage has its own meter?
Does the next teammate change the bill?
What happens if one launch sends a terabyte of traffic?
Which number should we put in next month's budget?

So we read the current Vercel and Supabase pricing pages line by line. This is the cost model we found, and why we built Lathe around one machine and one flat bill instead.

Prices below are in USD and were checked on September 21, 2026. Vendor pricing changes, so the linked pages are the source of truth.

The paid stack starts at $45 a month

For a commercial app, the simple starting point is Vercel Pro plus Supabase Pro.

Vercel Pro has a $20 monthly platform fee. That includes one deploying seat, $20 of monthly usage credit, 1 TB of Fast Data Transfer and 10 million Edge Requests. Each additional Owner or Member seat is another $20 a month. Billing is the platform fee, paid seats, add-ons and usage beyond the included amounts.

Supabase Pro starts at $25 a month for an organization. It includes $10 of compute credit, enough for one Micro project. Each extra Micro project adds $10 a month, and larger compute sizes cost more.

That makes the smallest paid Vercel + Supabase stack $45 a month before extra seats, extra projects, add-ons or overages.

For one founder, that can be a good deal. For a three-person team with all three deploying to Vercel, the Vercel side becomes $60 before usage: the $20 platform fee plus two additional $20 seats. Add Supabase Pro and the starting bill is $85.

The important word is starting.

Traffic is two different meters

A request to an app can cross both platforms.

Vercel serves the application and its assets. Supabase returns database rows, auth responses, files, realtime messages or function output. Each platform measures its own traffic.

On Vercel Pro, the first 1 TB of Fast Data Transfer and 10 million Edge Requests are included. After that, Vercel's regional pricing lists Fast Data Transfer at $0.15 to $0.35 per GB and Edge Requests at $2.00 to $3.20 per million, depending on region. The included $20 usage credit is applied before on-demand charges.

On Supabase Pro, the pricing page includes 250 GB of uncached egress and 250 GB of cached egress. They are separate quotas. Above them, uncached egress is $0.09 per GB and cached egress is $0.03 per GB. Supabase explains that egress can come from Database, Auth, Storage, Edge Functions, Realtime and Log Drains in its egress guide.

That distinction matters. "We transfer 300 GB a month" is not enough information to predict the Supabase bill. You need to know how much is cached and which services are producing it.

Supabase's own example makes this concrete. One Pro organization on Small compute with 300 GB of uncached egress and 800 GB of cached egress totals $51 after its compute credit: $25 for Pro, $15 for Small compute, $4.50 of uncached overage and $16.50 of cached overage, minus $10 of compute credit.

No individual line is shocking. The work is knowing which lines your product will create.

Usage does not stop at bandwidth

Traffic is only the most visible meter.

Vercel also prices build CPU time, image transformations, cache operations, Blob storage and transfer, observability and other infrastructure separately. The current pricing reference lists build usage at $0.0035 per CPU minute. The exact rate for many runtime and delivery resources depends on region.

Supabase Pro includes generous quotas, then charges by dimension. Its pricing page currently lists:

100,000 monthly active users, then $0.00325 per user
8 GB of database disk per project, then $0.125 per GB
100 GB of file storage, then $0.0213 per GB
2 million Edge Function invocations, then $2 per million
5 million Realtime messages, then $2.50 per million
500 peak Realtime connections, then $10 per 1,000
point-in-time recovery at $100 a month for seven days of retention
a custom domain at $10 per domain, per project, per month
a Log Drain at $60 per project per month, plus event and egress charges

A product rarely crosses every limit at once. That is not the point.

The point is that actual traffic turns one architecture into several independent pricing questions. A quiet database-heavy product and a file-heavy product can have the same user count and very different bills.

A launch month is hard to model from user count

Suppose a small product has one founder, one production project and ordinary traffic. Its paid floor is $45 a month.

Now suppose a launch pushes Vercel Fast Data Transfer to 1.5 TB in a region charging $0.15 per GB. Roughly 500 GB sits above the included 1 TB, creating about $75 of usage before the $20 monthly credit is applied. The Vercel portion moves from $20 to about $75 for that simplified example.

If the same month also puts Supabase at 500 GB of uncached egress, 250 GB is above its included quota. That adds $22.50.

The combined bill is now about $122.50 rather than $45, before any other compute, request, storage or add-on charges.

This is not a forecast for every app. It deliberately leaves out regional differences, cached traffic, request charges and other meters. It is an example of why "we have this many users" does not answer "what will infrastructure cost?"

Vercel and Supabase both offer spend controls and usage dashboards. Those are useful. They also become another part of operating the product: set budgets, watch the meters, decide whether to optimize or pay, and understand what a limit will do to production.

What we built instead

Lathe puts the app, Postgres, auth and optional Redis, CouchDB and NATS on one dedicated machine.

Plans are $15, $29, $49 and $89 a month. The plan price is based on machine size.

We do not add a line item for:

teammates
monthly active users
database connections
requests
function invocations
individual engines
backups
traffic within the included 20 TB monthly allowance

A workload may outgrow its machine and need a larger plan. That changes the monthly price from one known number to another known number. It does not turn each part of the stack into a separate meter.

Lathe itself runs on Lathe. The site, portal and API use the same application and database path customers use. If that path breaks, we feel it first.

Flat does not mean infinitely scalable

A useful pricing comparison should say what the cheaper-looking number does not buy.

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

Lathe is not the right fit if you need:

automatic horizontal scaling
a global edge runtime
high availability or automatic failover
read replicas
point-in-time recovery
a large enterprise support organization
an effectively unlimited serverless ceiling

Vercel and Supabase can absorb shapes of growth that one machine cannot. Their metering is connected to that model. If sudden global scale matters more than a fixed bill, paying for that architecture can be the right decision.

A mostly idle project may also be cheaper on free tiers than on any paid machine. We are not claiming that $15 always beats $0.

We are saying that a product which already needs a paid app, a paid database and predictable production behavior deserves a second calculation.

A practical cost checklist

Before choosing Vercel + Supabase, estimate:

the Vercel platform fee and every deploying seat
Fast Data Transfer and Edge Requests after the included amounts
build and runtime usage in the regions you use
the Supabase organization plan and compute size for every project
cached and uncached egress separately
database disk, file storage, MAUs, Edge Functions and Realtime
add-ons such as PITR, custom domains and Log Drains

Vercel + Supabase is probably the better fit when:

free tiers cover the real workload
automatic scaling and edge delivery matter more than bill predictability
you need platform features that a single machine does not provide
your team is comfortable monitoring several usage dimensions

A managed dedicated machine is worth considering when:

the app fits on one machine
you are a solo builder or small team
you want app, database and auth close together
you prefer choosing a machine size to forecasting several meters
standard Postgres credentials and a straightforward exit matter

Start with your own last 30 days

Do not migrate based on a hypothetical bill.

Take the last 30 days from both dashboards. Add the Vercel platform fee, seats and usage. Add the Supabase plan, project compute, egress, storage, users and add-ons. Then model one ordinary month and one launch month.

Compare those totals with the machine size the same workload would need. Include the architectural differences, not just the price.

We published a complete Next.js guestbook guide showing the app, database and auth flow on Lathe. There is also a broader guide to replacing Vercel + Supabase without becoming full-time DevOps.

Lathe has a 14-day trial with no card. Put a real side project on it, watch the machine under traffic and decide from evidence.

The point is not that usage pricing is dishonest. The vendors publish the numbers, and the model funds capabilities many products need.

The point is that once an app gets traffic, the real cost is the sum of the platform fee, people, projects, traffic and feature-specific meters. We wanted an option where that sum is one number.

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

Lathe — Sun, 20 Sep 2026 22:15:50 +0000

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:

Stay on managed platforms.
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.