DEV Community: Light Cloud

Rotate a Database Password With Only Seconds of Downtime

Julia — Mon, 02 Nov 2026 09:18:29 +0000

To rotate the password of a Light Cloud PostgreSQL database that a live app uses, choose the new password yourself, put it into the app's DATABASE_URL first, and click Rotate password with Set my own the moment the app's new deployment is live. In my test that caused 7 seconds of errors. Rotating first and updating the app afterwards caused almost two minutes.

This is part 6 of the database series. It uses the bookshop-db database from part 1 and a small API that reads from it.

What you will do

Deploy a small API that uses the database.
Choose a new password and build the new DATABASE_URL.
Save it on the app, then rotate the password when the deploy is live.

Why the order matters

A database has one password. Rotating it changes it at once: the old password stops working for new connections, and apps with the old one fail until they are updated. Updating an app's DATABASE_URL redeploys it, which took about a minute in my runs.

I measured both orders with a request to the API's /health every half second:

Order	Failed requests	Errors for
Rotate first, then update `DATABASE_URL`	145	107 seconds
Update `DATABASE_URL` first, rotate when the deploy is live	10	7 seconds

The second order works because the old deployment keeps serving with the old password until the new one takes over. The only gap is between the new deployment going live and your click on Rotate password. The errors were all password authentication failed, answered by the API with a 503.

Before you start

The bookshop-db database from part 1.
An app that uses it. To follow along, deploy the app folder of the repository from GitHub, as in the Express guide: set Root directory to app, name it bookshop-api, and add DATABASE_URL with the connection string plus ?sslmode=require&uselibpqcompat=true. Its /health checks the database.
A Light Cloud account on the Lite plan or higher.

Step 1: Choose the new password

Generate a random password of letters and digits. Those need no escaping in a connection string:

$ openssl rand -hex 16


# Run this in Git Bash, which comes with Git for Windows.
$ openssl rand -hex 16

It prints 32 random characters; yours will differ. Keep the password somewhere safe, such as your password manager.

Then write the new connection string: take the current one from the database's Credentials tab and replace only the password, the part between : and @:

postgresql://u_ ******:NEW_PASSWORD@bookshop-db-yourworkspace.db.light-cloud.io:5432/db******?sslmode=require&uselibpqcompat=true

Step 2: Save it on the app first

Open bookshop-api , Production , Settings.
Click Edit next to Environment Variables.
Replace the value of DATABASE_URL with the new connection string and click Save.

Saving starts a new deployment. The app keeps running on the old deployment, with the old password, which still works.

Step 3: Get the rotation ready

While the app deploys, open bookshop-db , Credentials in a second browser tab and click Rotate password :

Choose Set my own.
Paste the password from Step 1.
Do not click Rotate password yet.

The window warns: Apps using the current credentials will lose access until they are updated. Your app is already updated, it just is not live yet.

Step 4: Rotate when the deploy is live

Go back to the app tab and open Deployments. When the new deployment at the top says Deployed , switch tabs and click Rotate password :

The console confirms: Password updated - connected apps need the new credentials. Check the app:

$ curl https://main-bookshop-api-yourworkspace.light-cloud.io/health
{"status":"ok","database":"ok"}


PS> curl.exe https://main-bookshop-api-yourworkspace.light-cloud.io/health
{"status":"ok","database":"ok"}

My deploy took 56 seconds. The new deployment started failing a few seconds before I saw Deployed , and recovered the moment I rotated: 7 seconds of errors in total.

Step 5: Update everything else

The old password no longer works anywhere. Update every other place that has it:

other apps and environments that use the same database, such as preview environments,
your laptop's DATABASE_URL from part 1,
GUI tools like TablePlus or DBeaver,
scheduled jobs, such as the pg_dump backup from part 4.

If one of them uses the database a lot, rotate during a quiet hour.

The quick way

If a minute or two of errors is acceptable, for example on a staging database, click Rotate password and keep Generate a strong password. Then copy the new connection string from Credentials and update DATABASE_URL on every app. The console shows the new password right away.

Troubleshooting

password authentication failed for user "u_..."

The app still has the old password. Check that you saved the new DATABASE_URL on the right environment, and that its deployment has finished.

The new password was rejected

It must be 12 to 72 characters: letters, digits or !@#$%^&*()_-+=.,?, with no quotes, spaces or backslashes. Some of those characters also need encoding in a connection string (for example @ as %40), which is why Step 1 uses letters and digits only.

The app broke before I rotated

You rotated too late: the new deployment went live with the new password while the database still had the old one. Click Rotate password now; the app recovers at once.

Import Data into Light Cloud: Upload a .sql Dump or Stream It with psql

Julia — Sun, 01 Nov 2026 10:41:05 +0000

To import a SQL dump into a PostgreSQL database on Light Cloud, open the database in the console, go to the Backup tab, click Import dump and choose the file. Plain .sql and gzipped .sql.gz files both work. For large dumps, run the file with psql from your computer instead.

This is part 5 of the database series. It adds a publishers table to the bookshop-db database from part 1, first with the console and then with psql.

What you will do

Import a small SQL file with Import dump.
Check the new data with a query.
Import a second file with psql, the way to go for large dumps.

Before you start

The bookshop-db database from part 1.
The two files from the repository: imports/publishers.sql and imports/more-books.sql. If you cloned it in part 1, run git pull in its folder. Otherwise, download the files from GitHub.
For Step 4, psql from part 1.

Step 1: Look at the file

imports/publishers.sql is what a supplier might send you. It creates a table of three (made-up) publishers, adds a publisher_id column to books, and fills it in:

CREATE TABLE publishers (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  city TEXT
);

INSERT INTO publishers (name, city) VALUES
  ('Lighthouse Press', 'Edinburgh'),
  ('Northwind Books', 'Toronto'),
  ('Blue Harbour', 'Gdansk');

ALTER TABLE books ADD COLUMN publisher_id INTEGER REFERENCES publishers(id);

UPDATE books SET publisher_id = 1 WHERE author_id IN (1, 3);
UPDATE books SET publisher_id = 2 WHERE author_id = 2;
UPDATE books SET publisher_id = 3 WHERE author_id = 4;

Always read a dump before you import it: it runs with full access to your database.

Step 2: Import it

In the Light Cloud console, open bookshop-db and its Backup tab.
Click Import dump and choose publishers.sql.

The import starts as soon as you choose the file; there is no second confirmation. For this small file it finished within a few seconds, with the message Dump imported.

The import runs into the database as it is. Nothing is deleted first: tables the dump does not mention stay as they are, and a table that already exists is an error unless the dump drops it first.

Step 3: Check the result

Open the Data tab. The table list now has publishers. Ask how many books each publisher has:

SELECT p.name AS publisher, p.city, count(b.id) AS books
FROM publishers p
JOIN books b ON b.publisher_id = p.id
GROUP BY p.name, p.city
ORDER BY books DESC;

All 10 books have a publisher. The query box is explained in part 3.

Step 4: Import with psql

Import dump takes files up to 512 MB uncompressed, and the import has about four and a half minutes to finish. For bigger dumps, or to import from a script, run the file with psql and the DATABASE_URL from part 1:

$ psql "$DATABASE_URL" --single-transaction -v ON_ERROR_STOP=1 -f imports/more-books.sql
INSERT 0 2


PS> psql "$env:DATABASE_URL" --single-transaction -v ON_ERROR_STOP=1 -f imports/more-books.sql
INSERT 0 2

Two more books arrived. The two options make a failed import safe:

-v ON_ERROR_STOP=1 stops at the first error, instead of carrying on with the rest of the file.
--single-transaction runs the whole file as one transaction, so an error undoes everything the file already did. Your database is either fully imported or unchanged.

Import dump also stops at the first error, but keeps what ran before it. With psql, you choose.

What a dump may contain

The console and psql run the file with your database user's rights. That user owns your tables but is not a superuser, so:

Plain SQL only. A .sql file, or one gzipped as .sql.gz. The console rejects pg_dump -Fc archives, tar and zip files with a message saying so. Restore a -Fc archive with pg_restore instead.
No owners or permissions from another server. ALTER TABLE ... OWNER TO postgres fails with must be member of role "postgres", and GRANT ... TO some_user with role "some_user" does not exist. Create the dump with pg_dump --no-owner --no-privileges, like the console's own backups.
No CREATE DATABASE. It fails with permission denied to create database. Dump a single database without -C, and import it into the Light Cloud database you created.

A backup downloaded from any Light Cloud database, as in part 4, meets all three rules and imports as it is.

Troubleshooting

Import failed: ERROR: relation "publishers" already exists

The dump creates a table the database already has, for example because you imported the same file twice. I got exactly this on a second run; since it was the first statement, nothing changed. Import into an empty database, or drop the table first.

must be member of role "postgres"

The dump sets owners. See What a dump may contain.

The import took too long

The file needs more than the console's time limit. Run it with psql as in Step 4.

Where to Deploy a SaaS Boilerplate

Julia — Sat, 31 Oct 2026 18:29:42 +0000

For a boilerplate that has no paying customers yet, the cheapest place to run its app and a PostgreSQL database is Light Cloud at $5 a month, followed by Railway at $5 plus usage. Vercel, the host that ShipFast, Makerkit and Supastarter all point you to, costs $20 a month once the app takes money, plus the database. That gap matters most for Supastarter and Open SaaS, which keep their data in plain Postgres. ShipFast and Makerkit keep theirs in MongoDB Atlas or Supabase, so only the app moves and that service stays on its own bill.

We make Light Cloud, the first row below, so here is the method before the table. Every number links to the page it came from.

What the four kits actually need

A boilerplate is a promise that the boring parts are done. Where it runs is the part the kit can't decide for you, and each of the four says something different about it.

ShipFast is a Next.js app whose own stack list reads "MongoDB / Supabase" (shipfa.st). The deployment page is three lines long: push to a private GitHub repo, then "use your favorite hosting provider (Vercel for me)", or anywhere Next.js runs, naming Netlify and Render too (deployment docs). Its default database is a MongoDB Atlas cluster, opened to 0.0.0.0/0 so the host can reach it.

Makerkit's Next.js Supabase kit is built on Supabase for auth and data, and calls Vercel "the recommended hosting platform" (Vercel guide). It also documents Cloudflare and Docker. Its Docker guide generates a Dockerfile, switches Next.js to standalone output and runs the container with a 512 MB memory limit (Docker guide).

Supastarter runs on "any hosting provider that supports Node.js", recommends Vercel, and has guides for Render, Fly.io, Netlify, Docker, Coolify and Railway (deployment overview). Its database is PostgreSQL by default, through Prisma or Drizzle, with any Postgres provider (database docs).

Open SaaS sits on Wasp: a React client, a Node.js server and Postgres. The quickest route is Wasp's one-command deploy to Fly.io or Railway (Open SaaS docs), and Wasp has written guides for Render, Heroku, Netlify and Cloudflare as well (Wasp docs).

So the job is the same for all four: run one server-rendered app, keep a database next to it, and don't pay much for either before launch.

How we ranked

The reference app is one boilerplate app, server-rendered Next.js or a Wasp Node server, plus a PostgreSQL database and a custom domain, at about 1,000 requests a day. Each platform gets its cheapest plan that allows a paid product. Prices are list prices from the vendors' own pages, checked on 2026-10-13, in US dollars, no trial credits.

The first column shows which of the four kits names the platform in its own docs, because a written guide saves an evening. And the second shows whether the app costs anything while nobody is using it, which before launch is most of the day.

Kept running all month, with no scale to zero, the same app gets the Always on prices in the table. Light Cloud comes fifth of seven there at about $56, because an always-on instance needs the $19 Starter plan and a Micro costs about $52 a month. Platforms that run the app only as functions have no documented way to keep it running, so they're listed last.

The ranking

#	Platform	App + Postgres a month	Always on, a month	Named in the kits' docs	App while idle
1	Light Cloud	$5	about $56 (Starter, always-on Micro)	None of the four	Scales to zero, costs $0
2	Railway	$5 plus usage over $5	$5+	Open SaaS, Supastarter	Sleep is opt-in
3	Netlify	$9 plus credits beyond the plan	No always-on option	ShipFast, Supastarter	Functions, idle is free
4	Heroku	$10 to $12	$12	Open SaaS	Eco sleeps; Basic bills 24/7
5	Render	$13.30	$13.30	ShipFast, Supastarter, Open SaaS	No scale to zero documented
6	Vercel	$20 plus a database	No always-on option	ShipFast, Makerkit, Supastarter	Functions, nothing between requests
7	Fly.io	about $40	~$40	Open SaaS, Supastarter	Machines stop when idle

List prices from each vendor's pricing and docs pages, checked 2026-10-13. Light Cloud usage uses the pricing page's own assumption of 0.2 s of instance time per request. ShipFast on MongoDB Atlas and Makerkit on Supabase add that service's own bill. Taxes and bandwidth beyond included allowances excluded.

1. Light Cloud

Best for: founders who want the app and its Postgres on one $5 bill while nobody is paying.

Lite is $5 a month with $5 of usage included, a custom domain and one shared PostgreSQL database (pricing). The reference app uses about $4.24 of that: $4 for the database, about $0.20 for 1,000 requests a day at 0.2 s each, and a few cents of builds. Server-rendered Next.js runs on a Micro instance that scales between 0 and 3, and the Next.js tutorial shows the detection and the output: "standalone" setting that cut my image from 201 MB to 74 MB. That's the same switch Makerkit's Docker guide makes. For Supastarter or a Node backend, the Postgres tutorial covers the connection string, including the sslmode suffix that node-postgres needs.

None of the four kits mentions us, so you're on your own docs. We host Next.js and Node.js apps from a plain repository, and the database is a Postgres database on the same bill. Every branch gets branch preview URLs at no idle cost, and you can deploy from Cursor or Claude Code if that's how the kit got written in the first place.

Open SaaS deserves its own paragraph. The template gallery has an Open SaaS stack that creates the Wasp app and a shared Postgres database with DATABASE_URL already wired. But stacks are created always-on so the first visit is warm, and an always-on Micro is about $52 a month and needs Starter. Set min instances to 0 in Scaling afterwards and it bills like any other app, with a cold start of 3.1 to 3.7 seconds after a quiet spell.

What's missing: no MongoDB, so ShipFast's default database stays on Atlas. There are no cron jobs or background workers, which matters once the app needs a nightly job, and no built-in auth or email, which the kits bring themselves. Redirect files such as vercel.json are ignored. And the shared database tier runs in Belgium only.

2. Railway

Best for: Open SaaS and Supastarter users who want a documented deploy at the same starting price.

Hobby is $5 a month with $5 of usage included, and usage is billed by the RAM and CPU the services actually use: $10 per GB of RAM a month and $20 per vCPU a month (plans). Wasp's Railway command creates the client, the server and a Postgres service and wires DATABASE_URL for you (Wasp on Railway). Supastarter's docs quote Railway's $5 starting price themselves.

Railway also has cron jobs and private networking on every plan, the two things a SaaS tends to want by month three. Two catches: Railway recommends Pro, $20 a month, for commercial apps, and the free plan has no custom domains.

3. Netlify

Best for: Next.js kits that want first-party Postgres with real data in every preview.

Personal is $9 a month for 1,000 credits (plans). Function compute is 10 credits per GB-hour, so 1,000 requests a day at 0.2 s each with the default 1 GB of memory comes to about 17 credits a month; production deploys cost 15 credits each, so a busy week of shipping eats more than the traffic does. Netlify Database is a first-party managed Postgres, and each deploy preview gets its own database branch with a copy of the production data taken when the preview is created.

Netlify hasn't published a storage rate for the database yet, so the long-run price has a blank in it. Password protection is a Pro feature, not on Personal. When credits run out without auto recharge, every project on the team pauses.

4. Heroku

Best for: teams who already know git push heroku and want Wasp's Heroku guide.

An Eco dyno is $5 for 1,000 shared hours and sleeps after 30 minutes idle, but only personal apps can use it; Essential-0 Postgres is $5 (pricing). That's $10, or $12 with an always-on Basic dyno. Wasp keeps a written Heroku guide, so Open SaaS has a known path there.

Heroku needs a card before you deploy, and it moved to a sustaining engineering model on 2026-02-06: stability and security, not new features. Fine for an app you'll run for a while. Odd for one you're starting today.

5. Render

Best for: a kit with a separate long-running API, on fixed prices.

A Starter web service is $7 a month for 512 MB, and the smallest Postgres is $6 plus $0.30 per GB (pricing): $13.30. Render and Vercel are the two hosts named by three of the four kits; for Render it's ShipFast's deployment page, Supastarter's guide and Wasp's Blueprint guide. If you run Supastarter's API as its own service, which its docs suggest for a "long-running" API, Render's fixed instances and private network suit that shape.

The free tier spins down after 15 minutes and takes about a minute to wake, and free Postgres expires after 30 days (free tier docs), so a real product starts on paid instances that bill around the clock.

6. Vercel

Best for: Next.js kits deployed exactly the way their authors do it.

This is the path of least resistance, and three kits say so. The catch is the plan. ShipFast's FAQ says Vercel lets you "host a project for free", but Vercel's own fair use guidelines limit Hobby to non-commercial use and count taking payments as commercial. A SaaS needs Pro: $20 a month per deploying seat with $20 of usage included (Pro plan). The database comes from a Marketplace partner, billed separately.

Previews are excellent and on every plan. A shared password on staging costs $20 per project a month on Pro since the September 2026 change.

7. Fly.io

Best for: Open SaaS through Wasp's one-command deploy, with regions near your users.

Wasp's Fly command creates three apps: the client, the server and the database (Wasp on Fly). The smallest always-on machine is $2.19 a month, but Fly calls its self-managed Postgres officially unsupported, and Managed Postgres starts at $38 plus $0.28 per GB (Postgres docs). That puts a supported setup near $40.

There's no free tier for new accounts, and Fly doesn't support billing alerts yet.

Where the others beat us

The written guide is the big one. Every other row has at least one kit that tells you, step by step, how to deploy there; we have none, so you follow our Next.js tutorial instead of the kit's. If you picked Makerkit or ShipFast for Supabase or MongoDB, we only take the app, not the data layer. Railway gives Open SaaS a one-command deploy at our price, with the cron jobs a SaaS eventually needs. Netlify's previews copy production data into a database branch, while ours share the production database until you point them elsewhere. And if you want Vercel's Next.js features as the kit authors use them, Vercel is the honest answer.

Where we're ahead is the month before launch: one bill of $5 covering the app and Postgres, no cost while nobody visits, a preview of every branch, and a password on staging on any plan (the five-minute setup). If that is the stretch you're in, SaaS boilerplate hosting can stay at $5 until the first invoice goes out.

Which kit did you buy, and where did its docs send you?

Back Up a Database: Download a SQL Dump and Restore It

Julia — Sat, 31 Oct 2026 09:14:37 +0000

To back up a PostgreSQL database on Light Cloud, open the database in the console, go to the Backup tab and click Download backup. You get a complete SQL dump as a .sql.gz file. To restore it, unzip it and run it with psql against an empty database. For scheduled backups, run pg_dump with the connection string instead.

This is part 4 of the database series. It backs up the bookshop-db database from part 1, then proves the backup works by restoring it into a second database.

What you will do

Download a backup of bookshop-db.
Look inside it.
Restore it into a new database, bookshop-copy, and check the data.
Make the same backup from the terminal with pg_dump.

Before you start

The bookshop-db database from part 1.
psql and pg_dump, installed with psql in part 1. Use a current version: I used 18.6.
A Light Cloud account on the Lite plan or higher.

Step 1: Download the backup

Open bookshop-db , go to the Backup tab and click Download backup :

The console makes a fresh dump of the database and downloads it; for my small bookshop that took about a second. The file is named after the database and the time in UTC, for example bookshop-db-2026-09-25T15-41-43.sql.gz, and was 1.4 KB.

Open a terminal in the folder with the file, usually Downloads.

Step 2: Look inside

The file is gzip-compressed SQL. Unzip it and keep the original:

$ gunzip -k bookshop-db-*.sql.gz
$ head -n 8 bookshop-db-*.sql
--
-- PostgreSQL database dump
--

\restrict asCDvFHFw2eKvwY4n71bGzNGHJM0iLagWYa5QvYYBYmRpBkzvdW4DCtA642ddcH

-- Dumped from database version 15.18
-- Dumped by pg_dump version 16.15


# PowerShell has no gunzip, so extract the file with 7-Zip (www.7-zip.org):
# right-click it, choose 7-Zip, then Extract Here.
# Open the .sql file in Notepad. It starts with the same lines:
--
-- PostgreSQL database dump
--

\restrict asCDvFHFw2eKvwY4n71bGzNGHJM0iLagWYa5QvYYBYmRpBkzvdW4DCtA642ddcH

-- Dumped from database version 15.18
-- Dumped by pg_dump version 16.15

Your \restrict line has a different random key.

It is a plain SQL file made by pg_dump. Further down are CREATE TABLE statements for authors, books and reviews, their rows as COPY blocks, and the primary keys. It contains no owners or permissions, so it restores into any PostgreSQL database, not only the one it came from.

Step 3: Restore into a new database

A backup you have never restored is only a hope. Restore it into a second database to check it:

In the console, create a database named bookshop-copy, size Dev , as in part 1.
Copy its connection string from Credentials , add ?sslmode=require, and save it as COPY_URL:

$ export COPY_URL='postgresql://u_ ******:******** @bookshop-copy-yourworkspace.db.light-cloud.io:5432/db ******?sslmode=require'


PS> $env:COPY_URL = 'postgresql://u_ ******:******** @bookshop-copy-yourworkspace.db.light-cloud.io:5432/db ******?sslmode=require'

Run the SQL file against it:

$ psql "$COPY_URL" -f bookshop-db-*.sql
SET
SET
...
CREATE TABLE
CREATE SEQUENCE
ALTER SEQUENCE
...
COPY 4
COPY 10
COPY 1
...
ALTER TABLE


# Use your own file name after -f.
PS> psql "$env:COPY_URL" -f bookshop-db-2026-09-25T15-41-43.sql
SET
SET
...
CREATE TABLE
CREATE SEQUENCE
ALTER SEQUENCE
...
COPY 4
COPY 10
COPY 1
...
ALTER TABLE

Output is trimmed where you see .... The COPY lines are the rows: 4 authors, 10 books and 1 review, everything from parts 1 to 3.

Check it:

$ psql "$COPY_URL" -c "SELECT count(*) AS books FROM books;"
 books
-------
    10
(1 row)


PS> psql "$env:COPY_URL" -c "SELECT count(*) AS books FROM books;"
 books
-------
    10
(1 row)

The copy is complete. The same file restores into PostgreSQL on your laptop: point psql at the local database instead of COPY_URL.

Step 4: Back up from the terminal

The Download backup button is right for a backup before a risky change. For regular backups, run pg_dump from a script or a scheduled job, with the DATABASE_URL of bookshop-db from part 1:

$ pg_dump "$DATABASE_URL" --no-owner --no-privileges -f bookshop.sql


PS> pg_dump "$env:DATABASE_URL" --no-owner --no-privileges -f bookshop.sql

It prints nothing when it works. --no-owner --no-privileges makes the same kind of portable file as the console. My bookshop.sql was 5 KB and said Dumped by pg_dump version 18.6. Add -Fc for PostgreSQL's compressed custom format, which you restore with pg_restore instead of psql.

Keep backups somewhere other than your laptop's Downloads folder, and remember they contain all your data.

Step 5: Delete the copy

bookshop-copy has done its job. Open it, go to Settings , and click Delete Database :

Type bookshop-copy to confirm and click Delete. Check the name twice: deleting cannot be undone, and part 5 still needs bookshop-db.

Troubleshooting

invalid command \restrict

Your psql is older than the pg_dump that made the file. Recent pg_dump versions add \restrict and \unrestrict lines as a safety guard. An older psql prints invalid command \restrict and invalid command \unrestrict but restores everything else; in my tests with psql 14.13 and 17.5 all rows arrived. Update psql to get rid of the messages.

relation "authors" already exists

The target database already has these tables. Restore into an empty database, or drop the tables first.

Run SQL in the Browser: Queries, Joins and Quick Fixes on a Live Database

Julia — Fri, 30 Oct 2026 07:02:13 +0000

To run SQL on a Light Cloud PostgreSQL database from the browser, open the database's Data tab, type the query in the box above the table, and click Run query. The box is read-only by default, so a stray UPDATE or DELETE is rejected. To change data, tick Allow writes first.

This is part 3 of the database series. It uses the bookshop-db database from part 1 and the reviews table from part 2.

What you will do

Run a first query with a join and totals.
Join three tables.
See a write being rejected, then make a quick fix safely.

Before you start

The bookshop-db database from part 1, with the changes from part 2.
A Light Cloud account on the Lite plan or higher.

Step 1: Run a first query

In the Light Cloud console, open bookshop-db and its Data tab.
Click into the box that says SELECT * FROM my_table LIMIT 10; and paste this query. It shows how many books each author has, and what their stock is worth:

SELECT a.name AS author, count(b.id) AS books, sum(b.price * b.in_stock) AS stock_value
FROM authors a
JOIN books b ON b.author_id = a.id
GROUP BY a.name
ORDER BY stock_value DESC;

Click Run query , or press Cmd+Enter ( Ctrl+Enter on Windows and Linux).

The result appears under Query result , with the number of rows and how long the database took. Terry Pratchett has 3 books because of Mort, the book you added in part 2.

Step 2: Join three tables

Reviews point at books, and books point at authors. To see each review with its book and author, join all three:

SELECT b.title, a.name AS author, r.rating, r.body
FROM reviews r
JOIN books b ON b.id = r.book_id
JOIN authors a ON a.id = b.author_id;

The result has one row: Mort, Terry Pratchett, rating 5, "Funny, kind and about Death."

Queries like this are what the box is best at: quick questions about live data, without setting up a client. Another useful one, the books that are running low:

SELECT title, in_stock
FROM books
WHERE in_stock < 5
ORDER BY in_stock;

It returns The Cyberiad (2), Parable of the Sower (3) and The Left Hand of Darkness (4).

Step 3: Try a write

The shop raises the price of every Terry Pratchett book to 9.49. Paste this and click Run query :

UPDATE books SET price = 9.49
WHERE author_id = 2
RETURNING id, title, price;

It fails:

That is the safety net: the note under the box says Read-only session , and every statement that would change data is rejected. Nothing was changed.

Step 4: Make the fix with Allow writes

Tick Allow writes. The note turns orange: Writes enabled - statements run with full access to this database.
Click Run query again.

RETURNING id, title, price makes the statement list the rows it changed: three books, each now 9.49. Without RETURNING, the result says 0 rows , even though the update worked, because the statement itself returns no rows.

Untick Allow writes when you are done, so the next query is read-only again.

Before you write to a production database

A few habits that keep quick fixes quick:

Run the SELECT first. Write the WHERE clause as a SELECT (SELECT id, title, price FROM books WHERE author_id = 2;), check the rows, then turn it into the UPDATE or DELETE.
Always use WHERE. UPDATE books SET price = 9.49 without it changes every book.
Add RETURNING. You see exactly what changed.
Back up before big changes. The Backup tab downloads the whole database; part 4 shows how.
Leave schema changes to migrations. CREATE, ALTER and DROP belong in your app's migrations, so every environment gets them. Part 7 covers migrations.

Limits

A query stops after 10 seconds , with canceling statement due to statement timeout.
The result shows at most 500 rows , marked truncated - refine the query to see more. Add a WHERE or LIMIT.
A query can be up to 20,000 characters.
Several statements separated by semicolons all run; only the last one's result is shown.

For long jobs or large exports, connect with psql as in part 1.

Troubleshooting

cannot execute UPDATE in a read-only transaction

Allow writes is not ticked. The same applies to INSERT, DELETE, CREATE and every other statement that changes something.

canceling statement due to statement timeout

The query ran for more than 10 seconds. Narrow it with WHERE or LIMIT, or run it with psql.

relation "..." does not exist

The table name is misspelt, or the table is in another schema. The table list on the left shows the exact names.

Free REST API Hosting

Julia — Thu, 29 Oct 2026 17:31:02 +0000

If you want to host a small Express or FastAPI app for free, with no card and no surprise bill, Light Cloud's Free plan is the only one of the eight below that passes every check: it runs the app as it is, wakes in a few seconds and never bills you. It does that up to about 4,800 requests a day. Cloudflare Workers comes second and gives you far more room, 100,000 requests a day, but only for code written for its runtime. Vercel, Render, Google Cloud Run, Netlify, AWS Lambda and Railway are all free in some form, each with a catch the table names.

Disclosure: I make Light Cloud. The checks are written down below, so you can score the eight yourself.

How we ranked

"Free API hosting" means different things on different pricing pages, so I fixed the API first. It's an Express or FastAPI app serving 3,000 requests a day, each taking 0.2 seconds, which is the "steady" API on Light Cloud's own pricing page. No database for now; that comes at the end.

Each free plan then got a point for each of five checks:

it costs $0 for that API;
the vendor's current pages say no card is needed to sign up;
the app runs as it is, without being rewritten into a function format;
nothing documented makes the first request after a quiet spell wait about a minute, or fail;
the free plan has no end date and can't put a charge on a card.

Ties go to the plan whose vendor restricts less what you may run on it, such as production or commercial use, and then to the faster first request. Fly.io, Heroku, Koyeb and DigitalOcean aren't scored: Fly has no free tier for new accounts, Heroku dropped its free dynos in 2022, Koyeb has asked new users to choose a paid plan since February 2026, and DigitalOcean's free tier covers static sites only. Everything was checked on 2026-10-13.

The ranking

#	Platform	Points	Reference API a month	Card at sign-up	After an idle spell
1	Light Cloud	5	$0, uses $0.64 of the $1 included	No card	Answers in 3.1 to 3.7 s
2	Cloudflare Workers	4	$0, up to 100,000 requests a day	No card	No sleep documented
3	Vercel	4	$0 on Hobby, non-commercial only	Not stated	Functions, no sleep documented
4	Render	4	$0, one free web service	No card	Spins down; about a minute to wake
5	Google Cloud Run	3	$0 inside the free tier	Billing account	Scales to zero
6	Netlify	3	$0, about 70 of 300 credits	Not stated on current pages	Functions, no sleep documented
7	AWS Lambda	3	$0 inside the free tier	Not needed for most new accounts	Functions, no sleep documented
8	Railway	2	$1 credit, may not cover a month	No card	Sleep is opt-in; first request may 502

Vendors' own pricing, limits and docs pages, checked 2026-10-13. Reference API: 3,000 requests a day at 0.2 s each, no database. "Not stated" means the vendor's current pages don't say either way, so the point isn't given.

1. Light Cloud

Best for: a small API that should stay free, need no card and never send a bill.

Five points. The Free plan includes $1 of usage a month, 3 server apps and no card (pricing). Our pricing page works out this exact API: 3,000 requests a day at 0.2 s is 5 instance-hours a month at $0.12, plus two deploys, $0.64 in all. You push the repository and it runs; there are Express and FastAPI walkthroughs, and the same works to deploy Express, FastAPI, Go and Spring Boot APIs without a Dockerfile, with deploys on every git push.

Free never bills. If the $1 runs out, the API pauses until next month and nothing reaches your card, because there isn't one. On the same formula the $1 lasts up to about 4,800 requests a day; past that, Lite is $5 a month with $5 of usage. A container that has scaled to zero answers its first request in 3.1 to 3.7 seconds, then fast.

The limits, plainly: Free apps live on a light-cloud.io address, with no custom domain, and Free has no database at all. Your own domain and Postgres start on Lite, which is also where you get your own domain with free SSL. There's no cron and no private network between services.

2. Cloudflare Workers

Best for: APIs written for the Workers runtime that need far more free requests than anyone else gives.

Four points. Workers Free allows 100,000 requests a day, reset at midnight UTC (limits), and Cloudflare's plans page says no credit card is required. Go over and requests fail with Error 1027; nothing is billed. Nobody else here comes close on volume: that's 33 times the reference API.

The point it loses is the runtime. A Worker isn't a Node server or a container; you write for Cloudflare's runtime in JavaScript, TypeScript, Python or Rust (languages), and each invocation gets 10 ms of CPU on Free. Cloudflare's docs include a FastAPI guide for Python Workers, so a small FastAPI app may port with little work. An Express app built around a long-running server needs more.

3. Vercel

Best for: personal projects whose API lives next to a Vercel frontend.

Four points. Hobby includes 1 million function invocations and 4 hours of active CPU a month and can't buy more, so it can't bill you; go over and the feature pauses (Hobby). A Docker image can run as a function on every plan, in beta, so the app needn't change much.

The catch is the use, not the money. Vercel's fair use guidelines limit Hobby to non-commercial personal use, and a paid developer or taking payments counts as commercial. I also couldn't find a current Vercel page that says whether Hobby needs a card, so that point isn't given.

4. Render

Best for: running an unchanged app for free when a slow first request is fine.

Four points. A free web service runs any Docker or native app as it is, no card is needed, and a workspace gets 750 free instance hours a month, enough for one service around the clock (free tier). Without a card on file, going over the free bandwidth suspends free services instead of billing.

It loses the wake-up point. A free web service spins down after 15 minutes without traffic, and Render says waking takes about one minute. That's fine for a portfolio demo and painful for a mobile app's login call. Render also says plainly that free instances are not for production.

5. Google Cloud Run

Best for: the biggest free container allowance, if a billing account is fine.

Three points. The free tier covers 2 million requests and 180,000 vCPU-seconds a month (pricing), and the reference API uses 90,000 requests and about 18,000 vCPU-seconds. It runs your container unchanged and scales to zero.

But the free tier needs a Google Cloud billing account, and usage beyond it is billed at standard rates, not paused. Spend caps that pause Cloud Run at a budget became generally available on 2026-10-12, which helps. You'll also wire up a custom domain yourself.

6. Netlify

Best for: small function-based APIs next to a Netlify site.

Three points. The Free plan has 300 credits a month with a hard limit and is never billed (plans). By its rates the reference API uses about 18 credits for requests and 50 for function compute at the default 1 GB, around 70, plus 15 per production deploy. It also includes Netlify Database, a Postgres that sleeps after 5 idle minutes, which matters for an API.

Two points go missing: the API becomes Netlify Functions rather than your Express server, and the current pricing docs don't say whether a card is needed. When credits run out, every project on the team pauses, the site included.

7. AWS Lambda

Best for: teams heading for AWS anyway.

Three points. Lambda's free tier is one million requests and 400,000 GB-seconds a month (pricing); the reference API at 512 MB uses about 9,000. A function URL gives it an HTTPS endpoint, and most new customers sign up without a payment method.

The app needs adapting: a container image, for example, must include Lambda's runtime interface client. And AWS's Free plan closes the account after six months or when its credits run out, unless you move to the Paid plan, which bills usage beyond the free limits.

8. Railway

Best for: trying an API on the platform you'll pay $5 for later.

Two points. After a 30-day trial, the Free plan gives $1 of credit a month, needs no card and runs your app as it is (free plan). But Railway bills RAM at $10 per GB a month for what your process holds, so an API holding 100 MB around the clock uses the whole dollar before any CPU. Turn on sleep to save it and Railway warns the first request may return a 502. Railway's docs don't say what happens when the free credit runs out, so the last point isn't given either.

Where the others beat us

On volume, Cloudflare Workers wins without contest: 100,000 free requests a day against our roughly 4,800. If your API is JavaScript or Python and you're happy to write it for Workers, that's the better free home. Need a free database too? We have none on Free; Netlify includes one, and a free Neon or Supabase database works next to any row here. A custom domain on a free API is something we only offer from Lite. And if your API is part of a bigger AWS or Google Cloud setup, Lambda and Cloud Run sit closer to everything else you run.

What we do differently is the shape of the promise. No card, an unchanged Express or FastAPI app, a first request in seconds rather than a minute, and a plan that pauses instead of billing. If that's the free REST API hosting you were looking for, it's free hosting with no credit card up to the point where your API has real users, and then $5.

How many requests a day does your API actually get?

Browse and Edit Your Data Without a SQL Client: the Data Explorer

Julia — Thu, 29 Oct 2026 09:12:02 +0000

To browse and edit a PostgreSQL database on Light Cloud without a SQL client, open the database in the console and click the Data tab. It lists every table. Click a table to see its rows, click a row to edit it, and use Insert row , Columns and New to add rows, columns and tables.

This is part 2 of the database series. It uses the bookshop-db database and sample data from part 1.

What you will do

In the bookshop database, you will:

change the stock of one book,
add a new book,
add an isbn column to books,
create a reviews table and add reviews,
delete a row safely.

Before you start

The bookshop-db database with the sample data, from part 1.
A Light Cloud account on the Lite plan or higher.

Nothing to install: everything happens in the browser.

Step 1: Open a table

In the Light Cloud console, click bookshop-db in the sidebar.
Open the Data tab.
Click books in the table list.

The table shows 50 rows per page. Click a column name to sort by it. Nothing you do while browsing changes the data.

Step 2: Edit a row

The Dispossessed is back in stock. Click its row. The Edit row window shows every column with its type, and whether it may be empty (not null means it may not):

Change in_stock from 0 to 6.
Click Save changes.

Only the fields you changed are saved, so you cannot overwrite a column you did not touch. The console confirms with Row updated.

Step 3: Insert a row

Click Insert row above the table and fill in a new book:

Field	Value
id	leave empty
title	`Mort`
author_id	`2`
year	`1987`
price	`8.99`
in_stock	`10`

Click Insert. Empty fields get the column's default, so PostgreSQL picks the next id, 10. author_id 2 is Terry Pratchett in the authors table.

Step 4: Add a column

The shop wants to store ISBNs. Click Columns above the table, then Add column :

Name it isbn.
Choose the type text.
Leave NULL ticked, so existing books may have no ISBN yet.
Click the green tick.

Changes in this window apply at once. The pencil next to a column renames it, and the bin drops it. Click Done. Every book now has an isbn column showing NULL, which means empty.

Step 5: Create a table

Readers want to leave reviews. Click New next to Tables and fill in the New table window:

Table name : reviews.
The first column is already there: id, type serial , PK ticked. serial numbers new rows automatically, and PK makes id the primary key.
Second column: book_id, type integer , NULL not ticked.
Click Add column. Third column: rating, type integer , NULL not ticked.
Click Add column. Fourth column: body, type text , NULL ticked.

Click Create table. reviews appears in the table list, empty. Add two reviews with Insert row , leaving id empty each time:

book_id 10, rating 5, body Funny, kind and about Death.
book_id 1, rating 1, body test

Keep a primary key on every table you create here: the data explorer can only edit rows of tables that have one.

Step 6: Delete a row safely

The second review was a test. Tick its checkbox, then click Delete selected :

The console asks first, and says how many rows will go:

Check the number, then click Delete row. To delete a single row, you can also open it and click Delete row... in the Edit row window.

Deleting cannot be undone, and neither can dropping a column or a table. Before a big cleanup, download a backup from the Backup tab; part 4 shows how.

Check the result

Open books again and click id to sort. The Dispossessed has 6 in stock, Mort is book 10, and every book has an empty isbn:

The same changes are visible to anything that connects to the database, such as psql or your app.

Troubleshooting

Clicking a row does nothing

The table has no primary key, so the explorer cannot tell rows apart; the header above the rows says read-only - no primary key. Add a primary key with SQL, or edit such tables with SQL.

Could not save the row

The window shows the database's reason. The most common: a not null field left empty, or text in a number field.

Could not add the column

Adding a column that may not be empty fails on a table that already has rows, because the existing rows would have no value. Leave NULL ticked, fill in the values, and tighten the rule later with SQL.

Create a PostgreSQL Database in One Minute and Connect From Your Laptop

Julia — Wed, 28 Oct 2026 08:28:52 +0000

To create a PostgreSQL database on Light Cloud, click New... , New Database in the console and then Create database. A Dev database is ready in about ten seconds. To connect from your laptop, copy the connection string from the Credentials tab, add ?sslmode=require to the end, and pass it to psql.

This is part 1 of a series on databases. Here you create the database, load a small bookshop into it, look at it in the console, and connect from Node.js and Python. Later parts use the same database.

What you will build

A PostgreSQL database named bookshop-db with two tables, authors and books, that you can reach from:

psql in your terminal,
the Data tab in the console,
a Node.js script and a Python script.

Source code and sample data: github.com/light-cloud-com/tutorial-database-basics.

Before you start

A Light Cloud account on the Lite plan or higher: the Free plan has no databases.
Git and a terminal. On Windows, use PowerShell 7.
For the last step, Node.js 20 or later and Python 3.10 or later. I used Node.js 22 and Python 3.13.

Step 1: Install psql

psql is the PostgreSQL command-line client. You only need the client, not a PostgreSQL server.

$ brew install libpq
$ echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc
$ source ~/.zshrc


$ sudo apt install postgresql-client

On macOS this uses Homebrew. Homebrew does not put libpq on your PATH by itself, hence the second line. On Fedora and other Linux distributions, the package is also called postgresql.

On Windows, run the PostgreSQL installer and select only Command Line Tools. Then add its bin folder, for example C:\Program Files\PostgreSQL\17\bin, to your PATH and open a new PowerShell window.

Check that it works. Any recent version is fine; I used 17.5:

$ psql --version
psql (PostgreSQL) 17.5


PS> psql --version
psql (PostgreSQL) 17.5

Step 2: Create the database

In the Light Cloud console, click New... and then New Database.
Click PostgreSQL.
Name it bookshop-db and keep Size at Dev.
Click Create database.

In my run the database was Ready ten seconds later.

Which size to pick:

Dev runs on a shared instance, is ready in seconds, and allows 10 connections per database user. It is the right choice for development, side projects and these tutorials.
Starter (0.6 GB RAM) and Pro (1.7 GB RAM) get an instance of their own, take 10 to 20 minutes to create, and need the Starter plan or higher.

Step 3: Copy the connection string

Open the Credentials tab. It shows the host, port, database name, user and password, and the whole connection string. Click Copy next to the connection string:

Add ?sslmode=require to the end, and save it as DATABASE_URL in your terminal. The database only accepts encrypted connections, and this setting asks for one. Paste your own string instead of the stars:

$ export DATABASE_URL='postgresql://u_ ******:******** @bookshop-db-yourworkspace.db.light-cloud.io:5432/db ******?sslmode=require'


PS> $env:DATABASE_URL = 'postgresql://u_ ******:******** @bookshop-db-yourworkspace.db.light-cloud.io:5432/db ******?sslmode=require'

Keep the single quotes: they stop the shell from changing special characters in the password. The variable lasts until you close the terminal. It contains the password, so keep it out of Git and screenshots.

Step 4: Connect with psql

Check the connection:

$ psql "$DATABASE_URL" -c '\conninfo'
You are connected to database "db ******" as user "u_******" on host "bookshop-db-yourworkspace.db.light-cloud.io" (address "***") at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: none)


PS> psql "$env:DATABASE_URL" -c '\conninfo'
You are connected to database "db ******" as user "u_******" on host "bookshop-db-yourworkspace.db.light-cloud.io" (address "***") at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: none)

SSL connection confirms the connection is encrypted. To work interactively, run psql "$DATABASE_URL" (on Windows, psql "$env:DATABASE_URL") without -c, and type \q to leave.

Step 5: Load the sample data

Clone the repository and run its seed.sql against the database:

$ git clone https://github.com/light-cloud-com/tutorial-database-basics.git
Cloning into 'tutorial-database-basics'...
$ cd tutorial-database-basics
$ psql "$DATABASE_URL" -f seed.sql
psql:seed.sql:4: NOTICE: table "books" does not exist, skipping
DROP TABLE
psql:seed.sql:5: NOTICE: table "authors" does not exist, skipping
DROP TABLE
CREATE TABLE
CREATE TABLE
INSERT 0 4
INSERT 0 9


PS> git clone https://github.com/light-cloud-com/tutorial-database-basics.git
Cloning into 'tutorial-database-basics'...
PS> cd tutorial-database-basics
PS> psql "$env:DATABASE_URL" -f seed.sql
psql:seed.sql:4: NOTICE: table "books" does not exist, skipping
DROP TABLE
psql:seed.sql:5: NOTICE: table "authors" does not exist, skipping
DROP TABLE
CREATE TABLE
CREATE TABLE
INSERT 0 4
INSERT 0 9

The two notices are expected on a new database: the script first drops its tables so you can run it again to reset the data. You now have 4 authors and 9 books. Ask for the five oldest:

$ psql "$DATABASE_URL" -c "SELECT title, year FROM books ORDER BY year LIMIT 5;"
           title | year
---------------------------+------
 Solaris | 1961
 The Cyberiad | 1965
 A Wizard of Earthsea | 1968
 The Left Hand of Darkness | 1969
 The Dispossessed | 1974
(5 rows)


PS> psql "$env:DATABASE_URL" -c "SELECT title, year FROM books ORDER BY year LIMIT 5;"
           title | year
---------------------------+------
 Solaris | 1961
 The Cyberiad | 1965
 A Wizard of Earthsea | 1968
 The Left Hand of Darkness | 1969
 The Dispossessed | 1974
(5 rows)

Step 6: See the data in the console

Back in the console, open the Data tab and click books :

This is the data explorer: every table in the database, its rows, and a SQL box above them. The session is read-only unless you tick Allow writes , so browsing cannot change anything by accident. Part 2 covers editing rows and tables here.

Step 7: Connect from Node.js and Python

The repository has one small script per language. Each connects with DATABASE_URL and counts the books.

Python, with psycopg, uses the string exactly as you saved it:

$ python3 -m venv .venv
$ .venv/bin/pip install -r requirements.txt
$ .venv/bin/python connect/python.py
Connected from Python: 9 books


PS> python -m venv .venv
PS> .venv\Scripts\pip install -r requirements.txt
PS> .venv\Scripts\python connect\python.py
Connected from Python: 9 books

Node.js, with node-postgres, needs one more setting at the end, &uselibpqcompat=true:

$ npm install
$ DATABASE_URL="$DATABASE_URL&uselibpqcompat=true" node connect/node.mjs
Connected from Node.js: 9 books


PS> npm install
PS> $env:DATABASE_URL = "$env:DATABASE_URL&uselibpqcompat=true"
PS> node connect/node.mjs
Connected from Node.js: 9 books

npm install also prints how many packages it added. On Windows, the variable keeps the Node.js ending from now on, so run the Python script before the Node.js one.

The ending each client needs:

Client	Add to the connection string
psql, Python (psycopg), Prisma, GUI tools	`?sslmode=require`
Node.js (node-postgres, `pg`)	`?sslmode=require&uselibpqcompat=true`

In node-postgres 8, sslmode=require also checks the server's certificate against the certificate authorities Node.js trusts, and fails. uselibpqcompat=true gives require the meaning it has in every other PostgreSQL client: encrypt, without that check. Only node-postgres knows this setting; the others reject it.

To connect a GUI tool such as TablePlus, DBeaver or pgAdmin, copy the host, port, database name, user and password from the Credentials tab into a new PostgreSQL connection, and set SSL mode to require.

Troubleshooting

pg_hba.conf rejects connection ... no encryption

The client connected without encryption. Add ?sslmode=require to the end of the connection string.

unable to verify the first certificate

node-postgres with ?sslmode=require only. Add &uselibpqcompat=true.

invalid URI query parameter: "uselibpqcompat"

psql or psycopg got the Node.js ending. Remove &uselibpqcompat=true.

psql: command not found

psql is not on your PATH. On macOS, run the echo and source lines from Step 1. On Windows, add the PostgreSQL bin folder to PATH and open a new window.

password authentication failed

The password in the string is wrong or was changed. Copy the connection string again from the Credentials tab.

Password Protect a Website for Free

Julia — Tue, 27 Oct 2026 16:36:39 +0000

Three platforms let you password protect a website for free. Light Cloud does it with one shared password, set in four clicks on every plan, Free included. Cloudflare Access is free for teams under 50 people and makes each visitor sign in with a code sent to their email, which is safer and takes about a dozen steps to set up. Render has no setting for it, but its blog shows how to encrypt a static page at build time with PageCrypt. Everywhere else the password sits behind a paid plan: $20 a month on Netlify, $21 per user on GitHub, $29 on Koyeb and $40 on Vercel for one developer and one project.

We make Light Cloud, so it's our row at the top. Below is how the order was decided, and every row links to the vendor's own page so you can check it.

The September price change that started this

On 2026-09-09 Vercel moved Password Protection from a $150-a-month team add-on to $20 per protected project a month on Pro. For a team with one project, that's a price cut. An agency with ten client projects now pays $200 a month, more than the old add-on. The same day, Vercel let its account-based gate, Vercel Authentication, protect production deployments too, at no cost on every plan.

Answers to "how do I lock a staging site for free" tend to mix three different things: a shared password, a login with a personal account, and code you write yourself. They're priced very differently, so this table keeps them apart.

How we ranked

The scenario is the one I meet most: a commercial project has a staging site, and a client who has no account anywhere needs to open it, while search engines and strangers must not.

Each platform is priced on the cheapest plan where its own protection works, for one developer and one site, using list prices checked on 2026-10-13. "Commercial" rules out plans that forbid it, such as Vercel's Hobby. Ties on price are broken by the number of steps, which I counted from each vendor's own instructions, starting at the settings page and leaving out sign-up.

The table also says what the visitor has to type. A shared password is the least work for the client. Personal logins are better security, and more work for everyone. Neither is wrong.

The ranking

#	Platform	Password on one site a month	What the visitor enters	Steps in the vendor's docs
1	Light Cloud	$0, every plan	One shared password	4
2	Cloudflare	$0, Access Free under 50 users	Emailed code or company login	1 for preview links, about 12 for a hostname
3	Render	$0, with PageCrypt	Shared password, decrypted in the browser	3, plus inlining CSS, JavaScript and images
4	Netlify	$20, Pro	One shared password	5
5	GitHub Pages	$21 per user, Enterprise Cloud	GitHub sign-in with read access to the repo	3
6	Koyeb	$29, Pro	Username and password (HTTP basic auth)	1 CLI flag
7	Vercel	$40: $20 Pro seat plus $20 per project	One shared password	6
8	Railway	$5,000 committed-spend tier	Railway account sign-in	Not counted

Prices and steps from each vendor's docs and pricing pages, checked 2026-10-13, US dollars. Light Cloud steps from our own tutorial. Sign-up, plan upgrades and DNS changes not counted as steps.

1. Light Cloud

Best for: a staging site that one shared password should cover.

Password protection works on every plan, and the tutorial runs on Free: open the environment's Security tab, click Set password, type it twice, click Save password. It applies from the next request, with no redeploy. The check happens at the edge before the request reaches your app, so images and JavaScript are covered too, and the password page answers with a 401 and X-Robots-Tag: noindex, nofollow.

A few details I like. The password belongs to one environment, so production stays public while the staging branch is locked; the branch preview tutorial shows how a branch gets that environment in the first place. A visitor stays signed in for 12 hours. After 8 wrong guesses from one address within 15 minutes, further attempts are refused for a while. Clicking Change signs everyone out, which is what you want when a review ends. That's the whole of how we password protect a website for free: it comes with free hosting with no credit card, for static sites and containers alike.

Now the limits. Everyone shares one password, so you can't remove one person without changing it for all. There's no single sign-on. On Free the site lives on a light-cloud.io address with a small "by Light Cloud" link; a custom domain with automatic SSL starts on Lite at $5 a month.

2. Cloudflare

Best for: teams that want every visitor to sign in as themselves.

Cloudflare doesn't do shared passwords. It does Cloudflare Access, which is $0 for teams under 50 users and $7 per user a month, paid annually, above that (Access pricing). For preview links on Pages it's one setting, Settings > General > Enable access policy, which limits them to your Cloudflare account until you add people. That setting doesn't cover the pages.dev domain or a custom domain.

For staging.example.com you create a self-hosted Access application, and the domain has to be active on Cloudflare. The docs list nine actions before the optional settings. A client without a company login signs in with a one-time PIN sent by email, which new organizations add as an identity provider in three more steps. So about a dozen, once. In return you can let in one email address and later remove exactly that one.

3. Render

Best for: a small static site where a password in the page is good enough.

Render has no password setting. Its blog suggests PageCrypt, an open source library that encrypts an HTML file at build time; the browser decrypts it when the visitor types the password. Setup is three steps: add the dependency, change the build command, and set the password as an environment variable. Render's static sites are free, so the cost is $0.

Render is upfront about the catch. PageCrypt encrypts a single HTML file by default, so CSS, JavaScript and images have to be inlined into it to be protected, and there's only one shared password. It's a static-site trick; an API behind it needs its own authentication.

4. Netlify

Best for: agencies that want a password on every project for one flat price.

On the credit-based plans, the shared password comes with Pro, $20 a month with unlimited team members, and it's not available on Free or Personal (docs). Free and Personal can make a project private instead, but then only the Team Owner can see it, which doesn't help with a client.

Five steps under Project configuration > Visitor access > Project visibility: Edit visibility, choose Password, type it, choose Production and previews or Previews only, Save. There's no team-wide default password, so each project gets its own. The flat price is the real draw: the password adds no per-project fee, so twenty client sites don't multiply it.

5. GitHub Pages

Best for: internal docs for people who already work in the repository.

A GitHub Pages site can be published privately only if the organization uses GitHub Enterprise Cloud, which starts at $21 per user a month (pricing). Then only people with read access to the repository can open it, and only project sites from private or internal organization repositories qualify (docs).

The switch itself is three clicks: Settings, Pages, the visibility dropdown. It's a fine answer for an engineering handbook. For a client outside your GitHub organization, it isn't one.

6. Koyeb

Best for: an API or app that should answer only to a username and password.

Koyeb's CLI can put HTTP basic auth on every route of a service with one flag, --auth USERNAME:PASSWORD, or require an API key instead (CLI reference). That's the shortest setup in this table if you live in a terminal, and it protects an API as well as a website.

The price comes from the plan, not the feature. Since Koyeb announced it is joining Mistral AI, new users must pick a paid plan, and Pro is $29 a month with $10 of compute included. The browser shows its own plain sign-in box, which looks dated to a client but works everywhere.

7. Vercel

Best for: teams already on Pro that need a password on one or two projects.

Password Protection is $20 per protected project a month on Pro and isn't available on Hobby. Pro itself is $20 per deploying seat, so one developer with one protected project pays $40. The docs list six actions: pick the project, open Deployment Protection, flip the toggle, pick the environment, type the password, Save.

The free alternative is Vercel Authentication, on every plan. Visitors log in with a Vercel account and request access, which you approve, and Hobby allows one external user. For a team reviewing its own previews it's excellent; for a client it means asking them to create a Vercel account.

8. Railway

Best for: large teams that want staging services behind Railway accounts.

Railway's gate, announced on 2026-10-08, puts services such as staging previews and internal tools behind a Railway login. It requires the $5,000-a-month committed-spend tier. Below that tier, you'd put authentication into the app itself, which is a fine answer, just not a setting.

Where the others beat us

On security, Cloudflare Access wins outright. Each visitor proves who they are, you can remove one person without touching anyone else, and you can plug in a company login. Our shared password can't do any of that, and if it leaks, the fix is to change it and send the new one around. Vercel Authentication and GitHub's private Pages do the same job for teams whose reviewers already have accounts there.

For an agency with many client sites, Netlify's flat $20 covers a password on every project, and its team login can be tied to single sign-on through an identity provider. If you need production itself behind company sign-in, that's what these products are built for.

Where we're ahead is the plain case: a client, a staging link, a password in a message. It's four clicks on any branch preview URL, on any plan, and the git push deploys keep redeploying the protected branch without anyone touching the setting again. If you're choosing a host for the whole app, where to host a SaaS app prices the rest of it.

How many people outside your team need to open your staging site this month?

Kubernetes Alternatives for Small Teams

Julia — Sun, 25 Oct 2026 17:34:00 +0000

For a small team that wants containers without Kubernetes, the options with the least to learn are Light Cloud, Railway and Render: you connect a repository and get HTTPS URLs, with no cluster, no registry and no config file to master. Fly.io and Coolify each add one new thing, Google Cloud Run and AWS ECS add cloud permissions and plumbing, and Kamal, Docker Swarm and Nomad hand you the servers. Light Cloud is first because, of the three, it is also the cheapest way to keep a few quiet services online.

I run Light Cloud, so weigh that. The scoring below is simple enough to redo yourself from the vendors' own docs.

How we ranked

Kubernetes is hard for a small team for a boring reason: the list of things you have to understand before anything runs. Nodes, a registry, ingress, certificates, YAML for each object. The longer argument ran on this blog earlier this month, so this post stays practical.

Every option below got one point for each of these six things it makes you learn or run yourself before your first deploy:

machines you rent, patch and keep alive;
a config file in the tool's own format;
a container registry to set up and log in to;
HTTPS and load balancing you configure;
cloud permissions, such as IAM roles;
extra tools that must run next to it.

Writing a Dockerfile doesn't count, since every option accepts one. Fewer points rank higher. Where two options tie, the one where someone else runs the machines goes first, and after that the lower bill for a reference system: three small services that are quiet most of the day. Facts come from the vendors' own docs and pricing pages, checked on 2026-10-13. Self-hosted tools get "your servers" in the price column, because I couldn't check a server price on a page I trust.

The ranking

#	Option	Points	Who runs the machines	What you write	Three quiet services a month
1	Light Cloud	0	Light Cloud	Nothing; a Dockerfile is optional	$0 on Free, $5 with your own domain
2	Railway	0	Railway	Nothing required	$5 plus usage over $5
3	Render	0	Render	Nothing; render.yaml optional	$21
4	Fly.io	1	Fly.io	fly.toml, generated for you	up to $6.57
5	Coolify	1	You	Nothing; it has a dashboard	Your servers
6	Google Cloud Run	2	Google	IAM, plus a load balancer for your domain	$0 inside the free tier
7	AWS ECS Express Mode	2	AWS (Fargate)	IAM roles, an image in a registry	about $43
8	Kamal	3	You	config/deploy.yml	Your servers
9	Docker Swarm	3	You	Service definitions, an outside load balancer	Your servers
10	Nomad	3	You	Job files, plus Consul and Vault	Your servers

Scored from each vendor's own docs, checked 2026-10-13. Prices in US dollars from the vendors' pricing pages; "your servers" means the tool is free and you pay whoever hosts the machines. Kamal scores 4 once you run more than one server.

1. Light Cloud

Best for: teams that want push-to-URL with nothing to configure and services that cost nothing while idle.

Zero points. You connect a GitHub repository and each push builds and deploys; with a Dockerfile at the root it builds exactly that, and without one it detects the framework and writes the Dockerfile for you, so you can deploy Node.js, Python, Go and Java without a Dockerfile. Certificates are issued and renewed automatically. There is no registry to log in to and no IAM. Those git push deploys come with a preview URL per branch, and logs and metrics sit next to the deploy history.

Three quiet services fit the Free plan. The pricing page puts a quiet server app at about $0.10 a month of usage, so three use $0.30 of Free's $1, with no card (pricing). Your own domain and a database start on Lite at $5. That's pay-per-use container hosting in practice: every container scales to zero by default and bills by the hour while it runs.

Now the part a Kubernetes refugee should read twice. Services talk to each other over public HTTPS, not a private network; the microservices series shows the CORS and shared-secret setup that takes. There is no cron and no background worker type. An app scales to 3 instances on Free and Lite, 10 on Starter and 50 on Business, and a warm instance that never sleeps costs about $52 a month and needs Starter. A cold service takes 3.1 to 3.7 seconds to answer. And settings live in the console, not in a manifest in your repository (the CLI's small .lightcloud file only records which app a folder belongs to). That's the point of it, but it also means no infrastructure diff to review in a pull request.

2. Railway

Best for: small systems that need private networking and cron between services from day one.

Also zero points. Railway builds from your repository, and services in a project reach each other over a private WireGuard network with internal DNS, which is exactly what Light Cloud lacks (docs). Cron jobs and pull request environments come on every paid plan.

Hobby is $5 a month with $5 of usage included, billed by the RAM and CPU your services actually use (plans). Three quiet services may stay inside that, but I can't promise it: Railway has no fixed sizes, so it depends on how much memory your processes hold. Sleep is opt-in, and Railway warns that the first request to a sleeping service may get a 502.

3. Render

Best for: fixed prices per service, and a whole system in one optional file.

Zero points, because nothing beyond a repository is required. When you want it, a Blueprint describes services, databases and environment groups in a single render.yaml, which is the closest thing here to the manifests you'd keep in a Kubernetes repo. Private networking, background workers and cron jobs are all built in.

It ranks third on the tiebreak. A paid service is a fixed instance, the smallest $7 a month (pricing), so three services are $21 whether anyone calls them or not. The free instances spin down after 15 minutes and Render says not to use them in production.

4. Fly.io

Best for: the same containers in many regions, with a private network between them.

One point: fly launch writes a fly.toml for your app's Fly-specific settings (docs), and you'll edit it sooner or later. In exchange, every organization gets a private WireGuard network across regions, and machines can stop when idle so you pay only for their disk.

The smallest always-on machine is $2.19 a month (pricing), so three are at most $6.57, less if they stop. There is no free tier for new accounts, a card is required after the trial, and Fly says it doesn't support billing alerts yet.

5. Coolify

Best for: a Heroku-style dashboard on servers you already pay for.

One point, but it's the big one: you run the machines. Everything else is handled from a dashboard. Coolify builds with Nixpacks, a Dockerfile or Docker Compose, issues Let's Encrypt certificates, starts databases from a list and deploys pull requests separately (features). It also runs cron jobs inside your apps, which several managed rows can't.

Self-hosted Coolify is free with every feature; Coolify Cloud, where they run the dashboard and you bring the servers, is $5 a month for two servers plus $3 per extra one (pricing). The Coolify server needs 2 CPU cores, 2 GB of RAM and 10 GB of disk on its own (installation). Patching, backups to your own S3 bucket, and what happens when the box dies are yours.

6. Google Cloud Run

Best for: teams already on Google Cloud that want scale to zero at raw cloud prices.

Two points. gcloud run deploy --source builds from a Dockerfile or buildpacks and creates the registry for you (docs), which is kind. But you set up a billing account and IAM, and your own domain needs a load balancer or Firebase Hosting, because Cloud Run's built-in domain mapping is a preview that Google calls not production-ready.

Three quiet services cost $0 inside the free tier of 180,000 vCPU-seconds and 2 million requests a month (pricing). Light Cloud runs on Cloud Run, so this is the same engine with the setup handed back to you.

7. AWS ECS Express Mode

Best for: AWS shops that want Fargate with the load balancer and TLS done for them.

Two points. AWS says an Express Mode service needs only three things: a container image, a task execution role and an infrastructure role. It then creates the Fargate service, a load balancer with TLS, auto scaling and monitoring. The image has to live in a registry first, and the roles are IAM.

Express Mode is free; Fargate isn't. The smallest task, 0.25 vCPU with 0.5 GB, is about $8.89 a month around the clock in us-east-1 (Fargate pricing), and a load balancer adds about $16.20 before usage charges. Three services sharing one load balancer come to about $43, before the load balancer's usage charges.

8. Kamal

Best for: Linux-comfortable teams putting containers on cheap servers.

Three points on one server, four on more. You run the servers, you write config/deploy.yml, and you need a registry, because kamal setup builds the image, pushes it, and pulls it on each host (installation). On a single server kamal-proxy gets Let's Encrypt certificates for you; with more than one, you put a load balancer in front yourself.

What you get back is a lot: zero-downtime deploys to any Ubuntu box with an SSH key, under the MIT license, from the team at 37signals that uses it for their own apps. Kamal's own homepage is candid that you're probably better off with a fully managed service if basic Linux or Docker is still difficult.

9. Docker Swarm

Best for: a real multi-machine cluster for people who already know Docker Compose.

Three points: machines, service definitions, and a load balancer for outside traffic. Swarm is built into Docker Engine, so there is no extra orchestrator to install, and it gives you service discovery by DNS name, rolling updates and rollbacks. Docker's tutorial uses three Linux hosts with ports 2377, 7946 and 4789 open between them.

It is the gentlest way to learn what a cluster is. It's also a cluster, with managers, workers and reconciliation, and Docker's own docs call it an advanced feature and suggest plain Compose if you don't plan to run Swarm in production.

10. Nomad

Best for: mixed fleets that schedule containers, Java apps and VMs side by side.

Three points: machines, job files, and the tools Nomad expects next to it. HashiCorp describes Nomad as a single binary that focuses on scheduling and composes with Consul for service discovery and Vault for secrets. It schedules more than containers, which no other row here does.

The license matters for some teams: Nomad Community Edition is under the Business Source License, per HashiCorp's own page.

Where the others beat us

Plenty of places, and they're the reasons people pick Kubernetes in the first place. If your services must talk privately, Railway, Render and Fly give you a private network today and we don't. Cron jobs are built into Railway, Render and Coolify, and Render sells background workers as a service type. Once your services are busy around the clock, a server running Kamal or Coolify is far cheaper than our always-on price, and Render's fixed $7 beats our $52. Teams that want the whole system in a reviewed file will prefer Render's Blueprint or a Kamal config to our console. And Nomad runs workloads that aren't containers at all.

What we do better is the first step and the quiet months. There is nothing to install, no file to learn and no registry, and a service nobody calls costs nothing. For three small services that's $0 on Free, and the Kubernetes alternative for small teams I'd pick for a first product is the one where you can bring your own Dockerfile and be live before lunch.

Which of the six points would you happily take on, and which made you leave Kubernetes in the first place?

Heroku Alternatives in 2026

Julia — Fri, 23 Oct 2026 15:25:00 +0000

If your team opens a review app for every pull request, the cheapest Heroku alternative for a small app is Light Cloud at $5 a month, review apps included, against $16.80 for the same app and four review apps on Heroku. Railway starts at the same $5 and copies the database into each pull request environment, which we don't. If you rely on worker dynos and Heroku Scheduler, look at Render first: it feels the most like Heroku and lands at $16.10.

We make Light Cloud, the first row below. The method comes before the table so you can check every number on the vendors' own pages.

Why move off Heroku now

Nothing broke. On 2026-02-06 Heroku said it is transitioning to a sustaining engineering model "focused on stability, security, reliability, and support", and that Enterprise contracts will no longer be offered to new customers. Apps keep running, and prices for card-paying customers did not change. What changed is the direction: the platform you deploy to has stopped adding things.

The money side is older news. Free dynos and free Postgres ended on 2022-11-28, and you need a verified card before you can create an app. Any dyno scaled above zero bills whether or not it gets traffic; only Eco dynos sleep, and Eco is for personal apps, not team apps. For teams that live on review apps, that means paying for a dyno and a database per pull request while the reviewer is at lunch.

How we ranked

The reference app is the one from where to host a SaaS app: a React frontend, one Node.js API, a small PostgreSQL database and a custom domain, at about 1,000 API requests a day. On top of it I added the Heroku habit this post is about: four pull requests a month, each with a preview of the frontend and API that stays open for three days.

On Heroku that costs $12 for the app on a Basic dyno with Essential-0 Postgres (pricing), plus four review apps. Review apps are billed like normal apps, so a Basic dyno and Essential-0 for three days is about $1.20 each. Total: $16.80.

For every other platform I priced the cheapest way to get a preview of the frontend and API per pull request, with list prices from the vendor's own pages, checked on 2026-10-13, in US dollars. Whether that preview also gets its own database is in the table, because Heroku review apps can carry one and not every alternative copies it. The second column covers the other two Heroku habits: worker dynos and the Scheduler add-on.

Kept running all month, with no scale to zero, the same app gets the Always on prices in the table. Light Cloud comes last there at about $56, because an always-on instance needs the $19 Starter plan and a Micro costs about $52 a month. Every other platform here already runs the API around the clock at the price above, so their bills don't move.

The ranking

#	Platform	App + review apps a month	Always on, a month	Review apps	Scheduler and workers
1	Light Cloud	$5	about $56 (Starter, always-on Micro)	Every branch, shares the production database	Neither yet
2	Railway	$5 plus usage over $5	$5 plus usage over $5	Every pull request, own database	Cron jobs built in
3	DigitalOcean App Platform	$12 plus preview apps	$12 plus preview apps	Through GitHub Actions	Scheduled jobs and workers
4	Render	$16.10, or $43.50 with full-stack previews	$16.10	Per service on the free workspace; full stack on Pro	Cron jobs and workers
5	Koyeb	$29 plus usage over $10	$29 plus usage over $10	Through GitHub Actions	Workers; no scheduler documented
6	Fly.io	about $41	about $41	GitHub Action, one app, no database	Workers; cron is an app you run

List prices from each vendor's pricing and docs pages, checked 2026-10-13. Four pull requests a month, each previewed for three days. For comparison, the same app with four review apps is $16.80 on Heroku. Taxes and bandwidth beyond included allowances excluded.

1. Light Cloud

Best for: teams that open a review app for every pull request and are tired of paying for idle dynos.

Lite is $5 a month with $5 of usage included, a custom domain and one shared PostgreSQL database (pricing). The reference app uses about $4.33 of that: $4 for the database, around 20 cents for the API, a few cents of builds. Four previews add about eight cents, because a preview only costs its two builds and then sits at $0 until somebody opens it. That's the trade in pay-per-use hosting from $5 a month: no dyno waits for a reviewer.

You get a review app for every branch, frontend and API, on every plan including Free, and a pull request comment with the link. Deploys come from GitHub, so git push heroku main becomes a plain push to your repository and deploys on every git push take it from there. The database is managed Postgres in the same console; moving yours over is a plain-SQL pg_dump (the import doesn't take the custom format) and an upload of up to 512 MB.

The gaps a Heroku team will hit first: there is no worker app type and no scheduler, so a worker: line in your Procfile has nowhere to go. A branch preview uses the production database until you point it at another one, which is not what a Heroku review app with its own Postgres does; the preview tutorial shows the setup. Shared databases run in Belgium only. Containers scale to zero, so a quiet API answers its first request in 3.1 to 3.7 seconds, and an always-on instance needs Starter and costs about $52 a month.

2. Railway

Best for: review apps that copy the whole app, database included.

Hobby is $5 a month with $5 of usage included (plans), and usage is metered by the resource: $10 per GB of RAM a month and $20 per vCPU a month. Pull request environments mirror the production workloads, Postgres included, and are billed as normal usage while they exist. If the app and its previews stay under about half a GB of RAM on average, the bill stays at $5; busier review apps push it over.

Railway also has cron jobs (at least 5 minutes apart) and private networking on every plan, and a hard usage limit you can set from $10 (cost control). It recommends Pro, $20 a month, for commercial apps. Of everything here, it's the closest to Heroku's review apps at our price.

3. DigitalOcean App Platform

Best for: fixed container prices with workers and scheduled jobs.

A 512 MiB container is $5 a month and a development database $7 (pricing), so the app is $12 with the frontend on the free static tier. Worker components are priced like services, and scheduled jobs are billed only while they run, which covers both Heroku habits.

There is no review app switch. DigitalOcean documents a GitHub Actions workflow that deploys a separate app per pull request and deletes it on merge; each one is an ordinary app billed by the second. The development database has no backups by default, so a real product moves to managed Postgres from $15, and a payment method is needed before you create anything.

4. Render

Best for: the closest feel to Heroku, workers and cron included.

A Starter web service is $7 a month and the smallest Postgres $6 plus $0.30 per GB (pricing): $13.30, with the frontend as a free static site. On the free Hobby workspace each service gets its own pull request previews, billed at the service's rate, so four API previews for three days add $2.80. That's $16.10, about Heroku's bill, but those previews come without a database of their own. Full-stack preview environments that copy the database need the $25 Pro workspace, which makes it $43.50.

Render is where a Heroku app maps over with the least rethinking: web services, background workers, cron jobs (minimum $1 a month each), a private network and fixed monthly prices. What its docs don't describe is scaling a paid service to zero while it's idle, or a visitor password for a staging site.

5. Koyeb

Best for: worker services on a private network, on one paid plan.

New users have needed a paid plan and a card since Koyeb announced it is joining Mistral AI on 2026-02-17. Pro is $29 a month with $10 of compute included (pricing), so the reference app is $29 plus whatever passes $10. Workers are a service type, services talk over a private mesh, and scale to zero is in public preview with a 1 to 5 second cold start.

Previews per pull request come from a 2023 GitHub Actions tutorial, not a setting. I found no scheduled-job feature in the docs, and Koyeb says spending limits are still in the works.

6. Fly.io

Best for: apps that should run close to users in several regions.

Machines are cheap, from $2.19 a month always on (pricing), and can stop when idle. Postgres is the expensive part: Managed Postgres starts at $38 plus $0.28 per GB (docs). With four preview machines for three days each, about $41.

Fly's review apps come from a GitHub Action that deploys one app without other resources, so a database per pull request is your own workflow to write. Workers are just Machines; scheduled jobs run through Cron Manager, which you deploy as its own Fly app. No free tier for new accounts, and no billing alerts yet.

Where the others beat us

Worker dynos and Heroku Scheduler are the big ones. If your Procfile has a worker: line or your app depends on a nightly job, Render, Railway and DigitalOcean run those today and we can't. A review app with its own copy of Postgres is a Railway feature at our price, and a Render one on Pro. If your users are on several continents, Fly is the better home. And if your company buys software through procurement, Upsun is worth a call: its pricing page lists full-stack preview environments for every branch, a per-project fee and per-user licenses. I left it out of the table because I couldn't find its smallest app size next to the prices, so I can't price the reference app there.

Where we come out ahead is the bill for waiting. On Heroku a review app is a dyno and a database that run for as long as the pull request is open, and most of that time nobody is looking. Here the preview of every branch costs its build and then nothing, the API scales to zero when traffic stops, and a five-dollar plan covers the app, the database and the domain. If your Heroku invoice is mostly review apps, that's the comparison to run.

What's the first thing in your Procfile you'd have to change?

Free Hosting for Startups

Julia — Wed, 21 Oct 2026 16:11:11 +0000

Cloudflare stays free the longest for a startup whose app fits in Workers and static assets: custom domains, previews and extra people cost nothing, and the first bill is usually a $5 Postgres database. Light Cloud's first bill is also $5, and that $5 covers your own domain, the database and an API in any language, all in. Railway's step is $5 plus usage, Netlify's $9, and Vercel's is $20 per founder the day you take a payment.

We make Light Cloud, the second row below. It isn't first here, and the method explains why.

How we ranked

Every free plan ends the same way: the startup needs something the plan doesn't include. So this ranking asks two questions per platform. What forces the first bill, and how big is it?

The reference startup is small and ordinary: a frontend, one API, a PostgreSQL database and its own domain, with one founder deploying and about 1,000 API requests a day. Each price is the first monthly bill once the free plan no longer covers that stack, from each vendor's own pricing and docs pages, checked on 2026-10-13, in US dollars. Ties go to the platform whose free plan lasts longer before the bill arrives.

A third column covers the moment a co-founder starts deploying, because that is the second bill most startups meet. Commercial use matters too: one platform's free plan bans it outright, and it changes the answer for that row.

The ranking

#	Platform	First bill a month	What forces the first bill	Second founder
1	Cloudflare	$5, Postgres from PlanetScale	Postgres, or 100,000 requests a day	Free, no seat fee
2	Light Cloud	$5, all in	Your own domain or a database	Starter, $19 a month
3	Railway	$5 plus usage over $5	Your own domain, or a second project	Pro, $20 a month
4	Google Cloud Run	about $8, Cloud SQL	A database; card from day one	IAM, no seat fee
5	Netlify	$9, Personal plan	300 credits, about 20 production deploys	Pro, $20 a month
6	DigitalOcean App Platform	$12	Any backend; card for anything	No seat fee
7	Render	$13.30	Free Postgres expires after 30 days	Pro, $25 a month
8	Vercel	$20 per deploying seat	Commercial use, such as taking payments	$20 per deploying seat

List prices from each vendor's pricing and docs pages, checked 2026-10-13. Reference startup: frontend, one API, PostgreSQL, its own domain, one founder deploying, about 1,000 API requests a day. Taxes and usage beyond included allowances excluded.

1. Cloudflare

Best for: startups whose app fits in Workers and static assets.

Cloudflare's free plan is the most generous here if your code runs as a Worker. Workers Free allows 100,000 requests a day, static asset requests are free and unlimited, and a Pages project gets 100 custom domains and unlimited preview deployments on the free plan (limits). Cloudflare also says a Pages site can be managed by an unlimited number of users, so the co-founder costs nothing.

The first bill usually comes from the database. Cloudflare's own D1 is SQLite, not Postgres; since 2026-06-18 you can create a PlanetScale Postgres database billed on your Cloudflare invoice, and PlanetScale's single node starts at $5 a month. If D1 is enough for you, the bill stays at $0 for a long time.

The limits are real, though. A Worker gets 10 ms of CPU per request on the free plan, and past 100,000 requests a day requests fail with Error 1027 until midnight UTC (limits). Running a container needs Workers Paid, a $5 minimum. And Cloudflare's budget alerts only notify; they never cap spend.

2. Light Cloud

Best for: the smallest first bill that covers a container API in any language, Postgres and your domain.

Free costs $0 with no card: unlimited static sites, 3 server apps and a preview URL for every branch, with $1 of usage a month (pricing). It never bills you. When the $1 runs out, server apps pause until next month and static sites keep serving. The catch for a startup is plain: Free has no custom domain and no databases, and free pages carry a small "by Light Cloud" link.

So the first bill comes early, the day you point your own domain at the app or create a database, and it is Lite at $5 a month. That $5 includes $5 of usage, a custom domain with automatic SSL and one shared PostgreSQL database. The reference startup uses about $4.25 of it: $4 for the database, about 20 cents for the API and a few cents of builds. Your API can be Node, Python, Go, Java or .NET, from git push deploys or a Dockerfile.

Where it falls behind in this ranking: the second bill. Lite has one team member, so a co-founder who deploys means Starter at $19 a month. There are no cron jobs, workers or private networking, the shared database runs in Belgium only, and a scaled-to-zero API takes 3.1 to 3.7 seconds to answer its first request after a quiet spell.

3. Railway

Best for: a $5 first step with cron jobs and private networking built in.

After a 30-day trial with $5 of credit, Railway's Free plan gives $1 of credit a month, one project, three services and no custom domains (free trial docs). No card is needed. The first bill comes with your own domain or a second project: Hobby at $5 a month, with $5 of usage included (plans). Postgres is billed as usage like any other service.

Railway has extras we don't: cron jobs, private networking and pull request environments on every plan. Against it: Hobby is a single-developer workspace, and Railway recommends Pro, $20 a month, for commercial applications, which a startup with paying customers is.

4. Google Cloud Run

Best for: teams already in Google Cloud.

The compute is free for a long time. Cloud Run's free tier covers 180,000 vCPU-seconds and 2 million requests a month (pricing), far more than the reference API needs. But you need a billing account with a card to use it, and anything over the free tier is billed, not paused.

The database is the first bill: Cloud SQL's smallest shared-core instance is $0.0105 an hour, about $8 a month before storage (Cloud SQL pricing). Your own domain takes setup, because Cloud Run's domain mapping is in preview and Google calls it not production-ready. Since 2026-10-12, a spend cap can pause Cloud Run at a budget. People are managed through IAM, with no seat fee.

5. Netlify

Best for: frontend-heavy startups.

Netlify's free plan covers a lot of the reference startup: custom domains with SSL, functions, unlimited deploy previews and Netlify Database, a managed Postgres (plans). It is never billed. But it runs on 300 credits a month, and each production deploy costs 15 of them, so about 20 deploys use the lot. When credits run out, every project on the team pauses until next month.

The first bill is Personal at $9 for 1,000 credits. A co-founder can't join Free or Personal at all; Netlify's pricing page says those plans cannot add team member seats, so the second step is Pro at $20 a month with unlimited members. Password protection is a Pro feature too.

6. DigitalOcean App Platform

Best for: fixed monthly prices from the first bill.

The free tier is three static sites (pricing). Any backend is paid, and you need a payment method to create anything at all, even a free static site. The reference startup is a $5 container (512 MiB) plus a $7 development database: $12. There is no seat fee as the team grows.

The development database has no backups by default and is deleted with the app, so a real product moves to managed Postgres at about $15 soon after.

7. Render

Best for: predictable per-service prices.

Render's free tier needs no card and includes free web services and a free Postgres database (free tier docs). Two things force the first bill. Free web services spin down after 15 minutes without traffic and take about a minute to wake, and the free database expires 30 days after it is created. A Starter web service is $7 and the smallest Postgres $6 plus $0.30 per GB: $13.30.

The free workspace has one team member. A co-founder means the Pro workspace, $25 a month flat with unlimited seats, plus compute.

8. Vercel

Best for: Next.js startups that will pay per founder from the first payment.

Vercel's free Hobby plan is generous and includes custom domains, but its fair use guidelines restrict it to non-commercial personal use, and count a paid developer or taking payments as commercial. For a startup that is the trigger, whatever the traffic. Pro is $20 a month per deploying seat with $20 of usage included (Pro plan), and Postgres comes from a Marketplace partner, billed by them. Two founders deploying is $40.

Where the others beat us

Cloudflare beats us outright on staying free: your own domain, previews and a co-founder all cost nothing there, while our Free plan has no custom domain at all. If your app is JavaScript and fits in a Worker, start there. Netlify's free plan includes a custom domain and a database, which ours doesn't. Railway's $5 buys cron jobs and private networking we don't have. And DigitalOcean, Cloud Run and Cloudflare never charge for a second person, while our Lite plan stops at one.

Where we come out ahead is the shape of the first step. It is $5, it covers a container in whatever language the API is written in, a database and your domain on one invoice, and nothing on the free plan can ever bill you. If that's your startup's stack, our free hosting for startups turns into a $5 bill the day you need more, with a Postgres database ready in seconds included. A password on staging stays free on every plan; the staging tutorial takes five minutes. For the full monthly picture after launch, see where to host a SaaS app.

Which limit hit your startup first: the domain, the database or the second person?