DEV Community: Light Cloud

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?

Bring Your Own Dockerfile: Deploy Anything That Runs in a Container

Julia — Thu, 15 Oct 2026 09:00:00 +0000

To deploy any app on Light Cloud with your own Dockerfile, put the Dockerfile at the root of the repository, EXPOSE the port your app listens on, read that port from the PORT environment variable, push to GitHub and click Deploy. Light Cloud builds your Dockerfile as it is, with a layer cache that covers every stage, and runs the image. Anything that runs in a Linux container can be deployed this way.

In my run a Rust service was live 3 minutes after the first click, and a new instance answered 0.13 seconds after it started.

What you will build

A small word-counting API written in Rust with axum, a language Light Cloud does not build on its own. The Dockerfile makes it deployable:

POST /count returns the characters, words and lines of a text.
GET /health answers {"status":"ok"}.
A two-stage Dockerfile compiles in a large Rust image and ships only the binary.

Source code: github.com/light-cloud-com/tutorial-dockerfile-app.

When to bring your own Dockerfile

Light Cloud builds Node.js, Python, Go, Java, .NET, PHP, Ruby and static sites without one. Bring your own when:

your language is not on that list (Rust, Elixir, Deno, C++, ...);
you need system packages, such as ffmpeg or a PDF renderer;
you already have a Dockerfile that works and want exactly that image in production.

The four rules

Whatever is inside, a Dockerfile that works on Light Cloud follows four rules:

Listen on PORT, on 0.0.0.0. Light Cloud sets PORT; localhost inside a container is not reachable from outside.
EXPOSE that port. Light Cloud reads it to know where to send traffic.
Stop cleanly on SIGTERM. That is how an old instance is told to go.
Log to standard output. One JSON object per line with a severity gets the right level in the Logs tab.

Before you start

Rust 1.85 or later, for the 2024 edition; I used 1.97.1. Only needed to run the app on your machine: the build happens in Docker.
Git and a GitHub account.
A free Light Cloud account at console.light-cloud.com with GitHub connected.
A terminal with curl. On Windows, use PowerShell 7 and curl.exe, which ships with Windows 10 and 11.

Step 1: Create the app

$ cargo new tutorial-dockerfile-app
    Creating binary (application) `tutorial-dockerfile-app` package
$ cd tutorial-dockerfile-app
$ cargo add axum tokio --features tokio/full
      Adding axum v0.8.9 to dependencies
      Adding tokio v1.53.1 to dependencies
$ cargo add serde --features derive
      Adding serde v1.0.229 to dependencies
$ cargo add serde_json
      Adding serde_json v1.0.151 to dependencies


PS> cargo new tutorial-dockerfile-app
    Creating binary (application) `tutorial-dockerfile-app` package
PS> cd tutorial-dockerfile-app
PS> cargo add axum tokio --features tokio/full
      Adding axum v0.8.9 to dependencies
      Adding tokio v1.53.1 to dependencies
PS> cargo add serde --features derive
      Adding serde v1.0.229 to dependencies
PS> cargo add serde_json
      Adding serde_json v1.0.151 to dependencies

Output is trimmed. cargo new also creates a Git repository with a .gitignore for /target.

Step 2: Write the service

use axum::{Json, Router, http::StatusCode, routing::{get, post}};
use serde::{Deserialize, Serialize};
use serde_json::json;
use tokio::signal::unix::{SignalKind, signal};

#[derive(Deserialize)]
struct CountRequest {
    text: String,
}

#[derive(Serialize)]
struct CountResponse {
    characters: usize,
    words: usize,
    lines: usize,
}

// One JSON object per line; the Logs tab reads "severity" and "message".
fn log(severity: &str, message: &str) {
    println!("{}", json!({ "severity": severity, "message": message }));
}

async fn root() -> Json<serde_json::Value> {
    Json(json!({ "service": "word counter", "version": 3, "try": "POST /count with {\"text\": \"...\"}" }))
}

async fn health() -> Json<serde_json::Value> {
    Json(json!({ "status": "ok" }))
}

async fn count(Json(body): Json<CountRequest>) -> Result<Json<CountResponse>, (StatusCode, String)> {
    if body.text.len() > 100_000 {
        return Err((StatusCode::PAYLOAD_TOO_LARGE, "text is longer than 100000 bytes".into()));
    }
    Ok(Json(CountResponse {
        characters: body.text.chars().count(),
        words: body.text.split_whitespace().count(),
        lines: body.text.lines().count(),
    }))
}

#[tokio::main]
async fn main() {
    // Light Cloud passes the port in PORT; 8080 matches EXPOSE in the Dockerfile.
    let port = std::env::var("PORT").unwrap_or_else(|_| "8080".into());
    let app = Router::new()
        .route("/", get(root))
        .route("/health", get(health))
        .route("/count", post(count));

    let listener = tokio::net::TcpListener::bind(format!("0.0.0.0:{port}")).await.unwrap();
    log("INFO", &format!("listening on port {port}"));

    // Finish running requests when Light Cloud stops the instance with SIGTERM.
    axum::serve(listener, app)
        .with_graceful_shutdown(async {
            signal(SignalKind::terminate()).unwrap().recv().await;
            log("INFO", "SIGTERM received, shutting down");
        })
        .await
        .unwrap();
}

Rules 1, 3 and 4 are in the code: it binds 0.0.0.0 on PORT, it waits for SIGTERM to shut down, and it prints JSON log lines with a severity.

Step 3: Write the Dockerfile

# Stage 1: compile. The Rust toolchain is large, but it never reaches production.
FROM rust:1.97-slim AS builder
WORKDIR /app

# Build the dependencies first, with an empty main.rs, so this slow layer is
# cached and only rebuilt when Cargo.toml or Cargo.lock change.
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs && cargo build --release && rm -rf src

COPY src ./src
RUN touch src/main.rs && cargo build --release

# Stage 2: run. Only the binary goes into a small Debian image.
FROM debian:bookworm-slim
RUN useradd --system --uid 10001 app
COPY --from=builder /app/target/release/tutorial-dockerfile-app /usr/local/bin/app
USER app

# Light Cloud reads EXPOSE to know which port to send traffic to.
ENV PORT=8080
EXPOSE 8080
CMD ["app"]

Three habits in there are worth copying into any Dockerfile:

Two stages. The build stage has the compiler and every build tool; the final image has the binary and nothing else. The image you run is small and has less in it to attack.
Dependencies before source. Copying only Cargo.toml and Cargo.lock first, and building them on their own, puts the slow dependency build in a layer that survives code changes. The same pattern works as package.json then npm ci, or requirements.txt then pip install.
A non-root user. USER app means a bug in the app cannot write to the system. Port 8080 needs no special rights.

Keep the build context small:

target
.git

Step 4: Run it on your machine

You do not need Docker for this: the same code runs with Cargo.

$ cargo run --release
    Finished `release` profile [optimized] target(s) in 1.80s
     Running `target/release/tutorial-dockerfile-app`
{"message":"listening on port 8080","severity":"INFO"}


PS> wsl
$ cargo run --release
    Finished `release` profile [optimized] target(s) in 1.80s
     Running `target/release/tutorial-dockerfile-app`
{"message":"listening on port 8080","severity":"INFO"}

Output is trimmed; the first run also compiles every dependency. The SIGTERM handler uses Unix signals, which is right for a container that runs on Linux, so on Windows run the app inside WSL (with Rust installed there) or only in Docker. Stopping it with Ctrl+C sends SIGINT, not SIGTERM, so you will not see the shutdown line locally. From a second terminal:

$ curl -X POST http://localhost:8080/count -H "content-type: application/json" -d '{"text":"Bring your own Dockerfile.\nDeploy anything."}'
{"characters":43,"words":6,"lines":2}


PS> curl.exe -X POST http://localhost:8080/count -H "content-type: application/json" -d '{"text":"Bring your own Dockerfile.\nDeploy anything."}'
{"characters":43,"words":6,"lines":2}

If you have Docker, docker build -t word-counter . and docker run -p 8080:8080 word-counter run exactly what Light Cloud will run.

Step 5: Push and deploy

$ git add -A
$ git commit -m "Rust word counter with a multi-stage Dockerfile"
# Create an empty repository named tutorial-dockerfile-app on github.com/new first.
$ git remote add origin https://github.com/YOUR-USERNAME/tutorial-dockerfile-app.git
$ git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-dockerfile-app.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.


PS> git add -A
PS> git commit -m "Rust word counter with a multi-stage Dockerfile"
# Create an empty repository named tutorial-dockerfile-app on github.com/new first.
PS> git remote add origin https://github.com/YOUR-USERNAME/tutorial-dockerfile-app.git
PS> git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-dockerfile-app.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.

In the Light Cloud console, click New... , then Deploy from GitHub , and pick the repository. Light Cloud shows Dockerfile / Backend and Runs on a server : it found no framework it builds itself, and a Dockerfile that says how to build this one.

Port under Advanced is 8080, read from EXPOSE. Click Deploy. The first build compiles every dependency; in my run the service was live 3 minutes 17 seconds after the click.

$ curl -X POST https://main-tutorial-dockerfile-app-yourworkspace.light-cloud.io/count -H "content-type: application/json" -d '{"text":"Bring your own Dockerfile.\nDeploy anything."}'
{"characters":43,"words":6,"lines":2}


PS> curl.exe -X POST https://main-tutorial-dockerfile-app-yourworkspace.light-cloud.io/count -H "content-type: application/json" -d '{"text":"Bring your own Dockerfile.\nDeploy anything."}'
{"characters":43,"words":6,"lines":2}

Step 6: See the layer cache at work

Change something in src/main.rs, commit and push. Deploy on push rebuilds the image, and this time the dependency layers come from the cache. From the build logs of two pushes in a row:

Build	Dependency stage	App compile	Whole build
First, empty cache	51.2 s	7.5 s	1 min 55 s
After a code change	cached	8.0 s	1 min 12 s

The cache covers every stage of the Dockerfile, including the builder stage that never ships. That is why the order of COPY lines matters: everything above the first changed file is reused.

In the Logs tab the rollout is visible too: the new instance logs listening on port 8080 0.13 seconds after it starts, and the old one logs SIGTERM received, shutting down before it goes.

Troubleshooting

The deploy fails the health check: the container did not listen on the port

The app listens on 127.0.0.1 or on a fixed port. Bind 0.0.0.0 and read PORT. Check that EXPOSE matches what the app uses when PORT is not set.

Serverless Was a Pricing Model, Not an Architecture

Julia — Wed, 07 Oct 2026 09:36:41 +0000

In November 2014, AWS introduced Lambda with a sentence developers had waited a decade to hear: run code without thinking about servers. The fine print arrived immediately after the applause. Your code had to be a stateless function. It had to finish inside five minutes, a cap that stood until October 10, 2018, when it grew to a still-arbitrary fifteen. It woke up cold, sometimes slowly, at exactly the moments you were being watched. And it billed per request and per gigabyte-second, which was the one part of the announcement that was genuinely new.

Here's the thesis, a decade on: serverless was never an architecture. It was a pricing model, the first mainstream compute bill that hit zero when idle, and the architecture everyone spent years learning was just the container that pricing shipped in. Once you see which part was the invention and which part was the packaging, the last ten years of system design read differently, and so does what comes next.

Designing for the meter

Watch what teams actually built, because the meter's fingerprints are on all of it. Functions couldn't hold state, so state moved into queues, tables, and event buses, and simple call chains became distributed choreography with a dashboard per hop. Functions couldn't run long, so workflow services existed to stitch fifteen-minute fragments into things that were, functionally, long-running processes wearing a disguise. Cold starts punished the request path, so teams paid for provisioned concurrency, which is a fee for making scale-to-zero not scale to zero. Every one of these patterns has a euphemistic name and a conference talk, and every one is a workaround for a constraint that existed to make the billing granularity possible, at 2014's technology, on 2014's virtualization.

None of that was malice. It was the meter shaping the buildings, the way pricing always shapes architecture when the two live together long enough, and it produced systems whose complexity was justified by a bill rather than by a requirement. "We went serverless" too often meant "we refactored a web app into forty functions to make our idle time free", which is a trade with a name in any other market: paying with labor for a discount.

In fairness to 2014, the constraints began as physics rather than ideology. Billing per request required isolation cheap enough to spin up per request, and the virtualization of the day couldn't do that for arbitrary long-running processes, so the function shape was an honest engineering compromise. AWS then built Firecracker, its microVM layer, precisely to make that isolation nearly free, and the compromise quietly expired. The constraints outlived their reason, the way constraints do once a generation of best practices has calcified around them and a certification industry depends on their permanence.

The tell

The proof that the architecture was packaging arrived when the pricing escaped it. Billing by the second, scaling to zero, paying nothing while idle: all of that turned out to be perfectly possible for ordinary containers running ordinary processes with ordinary state and no duration caps, which is how a preview environment costs cents and how a normal full-stack app bills a few dollars without being rewritten into event confetti. The moment scale-to-zero economics existed without the function shape, the function shape stopped being the price of admission, and the interesting question became visible: if you could have had the bill without the contortions, what were the contortions for?

That's what "serverless" should have meant from the beginning, and what we've built our platform around: the pricing revolution applied to ordinary software. Your app, your framework, your process model, billed like Lambda, shaped like nothing in particular. The revolution was in the meter. It was always in the meter.

The steelman: the constraints were the point

The strongest defense of classic serverless deserves a fair paragraph, because it's partly right. Event-driven functions are genuinely the correct architecture for a real class of work: webhooks, glue code, bursty parallel jobs, anything that's naturally a small reaction to an event, and forcing statelessness imposed a discipline that made a generation of systems more crash-tolerant than their authors would have chosen to build. Lambda also pioneered the operational bar, patching, capacity, isolation as someone else's problem, that everything since gets measured against. The people who loved it weren't wrong about what they loved.

Conceded, and the concession has a boundary: a good pattern for reactive glue was sold as a destination architecture for everything, and the selling worked because the bill was irresistible and came bundled. The sin was never the function; it was teaching a decade of developers that the meter's constraints were best practices, so thoroughly that "can this be a Lambda" became a design review question, asked before "what is this program". Architectures should be chosen by the shape of the problem. Bills should reward you for choosing well, and the two decisions should never have been the same decision. Unbundling them is the actual legacy Lambda deserves: it proved the industry would rearchitect anything for a fair meter, and the fair meter no longer asks for the rearchitecture.

So run the disentangling exercise on your own stack. List what's function-shaped because the problem is event-shaped, and what's function-shaped because in 2019 that was the only door to a fair bill. The first list is fine where it is. The second list is a refactoring you were paid to do once and are paying to maintain forever, and the fair bill comes without it now. How long is your second list?

FastAPI in Production: From main.py to a Public URL

Julia — Mon, 05 Oct 2026 09:00:00 +0000

To deploy a FastAPI app on Light Cloud, put fastapi[standard] in requirements.txt, keep the app object as app in main.py, push to GitHub and click Deploy in the console. Light Cloud detects FastAPI, installs the requirements and starts uvicorn main:app on the container's port. No Dockerfile, no Procfile. The interactive docs at /docs are online with the API.

In my run the first deploy took 97 seconds.

What you will build

A small book API with validation by Pydantic, live on a light-cloud.io address, with its Swagger docs:

The title, Reading List API , comes from an environment variable set in the console.

Source code: github.com/light-cloud-com/tutorial-fastapi-api.

Before you start

Python 3.10 or later (what FastAPI 0.141 requires); I used Python 3.13.
Git and a GitHub account.
A free Light Cloud account at console.light-cloud.com with GitHub connected.
A terminal with curl. On Windows, use PowerShell 7 and curl.exe, which ships with Windows 10 and 11.

Step 1: Create the project and a virtual environment

$ mkdir tutorial-fastapi-api
$ cd tutorial-fastapi-api
$ python3 -m venv .venv
$ source .venv/bin/activate


PS> mkdir tutorial-fastapi-api
PS> cd tutorial-fastapi-api
PS> py -m venv .venv
PS> .venv\Scripts\Activate.ps1

On Windows, mkdir also prints a short table describing the new folder. Your prompt shows (.venv) once the virtual environment is active.

List the dependencies. fastapi[standard] brings uvicorn and the fastapi command with it; the version pin makes the build install exactly what you tested:

fastapi[standard]==0.141.1


$ pip install -r requirements.txt
Successfully installed ... fastapi-0.141.1 ... pydantic-2.13.5 ... starlette-1.7.0 ... uvicorn-0.54.0 ...


PS> pip install -r requirements.txt
Successfully installed ... fastapi-0.141.1 ... pydantic-2.13.5 ... starlette-1.7.0 ... uvicorn-0.54.0 ...

Output is trimmed to the main packages.

Keep the virtual environment out of Git:

.venv/
__pycache__ /
.env

Step 2: Write the API

import os

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

# The title shows at the top of the interactive docs at /docs.
# Set API_TITLE on Light Cloud to change it without touching the code.
app = FastAPI(title=os.getenv("API_TITLE", "Book API"))

class BookIn(BaseModel):
    title: str = Field(min_length=1, max_length=200)
    author: str = Field(min_length=1, max_length=100)
    year: int = Field(ge=1450, le=2100)

class Book(BookIn):
    id: int

# In memory, so the list starts empty again after every restart.
books: dict[int, Book] = {}

@app.get("/")
def root():
    return {"message": "Hello from FastAPI", "docs": "/docs"}

@app.get("/health")
def health():
    return {"status": "ok"}

@app.get("/books")
def list_books() -> list[Book]:
    return list(books.values())

@app.post("/books", status_code=201)
def add_book(book: BookIn) -> Book:
    new = Book(id=len(books) + 1, **book.model_dump())
    books[new.id] = new
    return new

@app.get("/books/{book_id}")
def get_book(book_id: int) -> Book:
    if book_id not in books:
        raise HTTPException(status_code=404, detail="Book not found")
    return books[book_id]

Two details matter for the deploy. The file is called main.py and the FastAPI object is called app: that is what Light Cloud starts, as main:app. And the code never picks a port; the server that runs it does.

Step 3: Run it on your machine

$ fastapi dev main.py
 🌐 Server started at http://127.0.0.1:8000
    Documentation at http://127.0.0.1:8000/docs


PS> fastapi dev main.py
 🌐 Server started at http://127.0.0.1:8000
    Documentation at http://127.0.0.1:8000/docs

Output is trimmed. In a second terminal, add a book and send one that breaks the rules:

$ curl -X POST http://127.0.0.1:8000/books -H "content-type: application/json" \
  -d '{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999}'
{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999,"id":1}
$ curl -X POST http://127.0.0.1:8000/books -H "content-type: application/json" \
  -d '{"title":"","author":"Nobody","year":3000}'
{"detail":[{"type":"string_too_short","loc":["body","title"],"msg":"String should have at least 1 character","input":"","ctx":{"min_length":1}},{"type":"less_than_equal","loc":["body","year"],"msg":"Input should be less than or equal to 2100","input":3000,"ctx":{"le":2100}}]}


PS> curl.exe -X POST http://127.0.0.1:8000/books -H "content-type: application/json" `
  -d '{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999}'
{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999,"id":1}
PS> curl.exe -X POST http://127.0.0.1:8000/books -H "content-type: application/json" `
  -d '{"title":"","author":"Nobody","year":3000}'
{"detail":[{"type":"string_too_short","loc":["body","title"],"msg":"String should have at least 1 character","input":"","ctx":{"min_length":1}},{"type":"less_than_equal","loc":["body","year"],"msg":"Input should be less than or equal to 2100","input":3000,"ctx":{"le":2100}}]}

The second request gets a 422 with both problems listed. Pydantic checked the body against BookIn before your function ran. Stop the server with Ctrl+C.

Step 4: Push it to GitHub

$ git init -b main
$ git add -A
$ git commit -m "FastAPI book API"
# Create an empty repository named tutorial-fastapi-api on github.com/new first.
$ git remote add origin https://github.com/YOUR-USERNAME/tutorial-fastapi-api.git
$ git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-fastapi-api.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.


PS> git init -b main
PS> git add -A
PS> git commit -m "FastAPI book API"
# Create an empty repository named tutorial-fastapi-api on github.com/new first.
PS> git remote add origin https://github.com/YOUR-USERNAME/tutorial-fastapi-api.git
PS> git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-fastapi-api.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.

Check that git status did not list .venv: the build installs the packages itself from requirements.txt.

Step 5: Deploy it

In the Light Cloud console, click New... , then Deploy from GitHub.
Search for tutorial-fastapi-api and click it.

Light Cloud shows FastAPI / Backend , based on requirements.txt, and Runs on a server :

Open Advanced - build settings, environment variables, domain, scaling. Port is already 8000, the port uvicorn is started on. Leave it.

Under Environment variables , click Add variable and add API_TITLE with the value Reading List API.

Click Deploy and wait for Deployed (97 seconds in my run: the first build installs every package). The URL card has the address:

Step 6: Use the live API and its docs

$ curl https://main-tutorial-fastapi-api-yourworkspace.light-cloud.io/
{"message":"Hello from FastAPI","docs":"/docs"}
$ curl -X POST https://main-tutorial-fastapi-api-yourworkspace.light-cloud.io/books -H "content-type: application/json" \
  -d '{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999}'
{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999,"id":1}


PS> curl.exe https://main-tutorial-fastapi-api-yourworkspace.light-cloud.io/
{"message":"Hello from FastAPI","docs":"/docs"}
PS> curl.exe -X POST https://main-tutorial-fastapi-api-yourworkspace.light-cloud.io/books -H "content-type: application/json" `
  -d '{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999}'
{"title":"The Pragmatic Programmer","author":"Andrew Hunt","year":1999,"id":1}

The first request after a quiet period takes a few seconds (3 seconds in my run) while an instance starts.

Now open /docs on your address. Swagger UI lists every route with the title from API_TITLE. Expand POST /books , click Try it out , edit the example and click Execute :

Your id may differ. In my run it was 3, although I had added only one book before, from a different terminal. That is the in-memory list at work: each instance keeps its own copy, and the next section explains why that matters.

Where data lives

The books dictionary lives in the memory of one running instance. On Light Cloud, as on any cloud platform:

a new deploy replaces the instances, so the list starts empty;
with Min instances at 0, the API stops when idle and starts empty on the next request;
under load several instances run at once, each with its own list.

That is fine for a demo and wrong for real data. Store it in a database: a frontend, two APIs and a database shows a FastAPI service with PostgreSQL through psycopg.

Troubleshooting

The deploy fails because the app cannot be found

Light Cloud starts uvicorn main:app, or app:app if the file is app.py. If your app is in src/api.py or the object has another name, uvicorn cannot find it. Move the entry point to main.py at the root with app = FastAPI(), or set Root directory to the folder that contains main.py.

FastAPI is not detected

Light Cloud looks for fastapi in requirements.txt or pyproject.toml at the root (or in the Root directory ). A project that installs FastAPI only through another tool's lock file is not detected; add a requirements.txt.

Put a Node.js Express API Online: Port, Environment Variables and Logs

Julia — Sun, 04 Oct 2026 09:00:00 +0000

To put an Express API online with Light Cloud, make it listen on the port in process.env.PORT, read its settings from environment variables, push it to GitHub and choose Deploy from GitHub in the console. Light Cloud detects Express, runs npm ci and npm start in a container and gives the API an HTTPS address. No Dockerfile is needed. If every log line is JSON with a severity field, the Logs tab shows each request with its level.

In my run the first deploy took 72 seconds, and a changed environment variable was live 59 seconds after clicking Save.

What you will build

A small Express 5 API with three routes, live on a light-cloud.io address:

GET / returns a greeting and the Node.js version.
GET /hello/:name greets by name.
GET /health answers {"status":"ok"}.

On the way it picks up three habits every Node.js API needs in the cloud: it listens on the port it is given, it reads settings from environment variables, and it writes one JSON log line per request.

Source code: github.com/light-cloud-com/tutorial-express-api.

Before you start

Node.js 18 or later (Express 5 requires 18); I used Node.js 22.
Git and a GitHub account.
A free Light Cloud account at console.light-cloud.com with GitHub connected. The free Hobby plan includes one service, which is enough for this API.
A terminal with curl. On Windows, use PowerShell 7 and curl.exe, which ships with Windows 10 and 11.

Step 1: Create the project

$ mkdir tutorial-express-api
$ cd tutorial-express-api
$ npm init -y
$ npm install express
added 68 packages, and audited 69 packages in 692ms

found 0 vulnerabilities
$ npm pkg set type=module scripts.start="node server.js" main=server.js


PS> mkdir tutorial-express-api
PS> cd tutorial-express-api
PS> npm init -y
PS> npm install express
added 68 packages, and audited 69 packages in 692ms

found 0 vulnerabilities
PS> npm pkg set type=module scripts.start="node server.js" main=server.js

On Windows, mkdir also prints a short table describing the new folder. The last command sets up package.json: type=module lets you use import, and the start script is how Light Cloud starts the app. Output is trimmed.

Keep node_modules out of Git:

node_modules
.env

Step 2: Write the API

import express from "express";

// Light Cloud tells the app which port to listen on through PORT.
// 8080 is the fallback for running it on your own machine.
const PORT = Number(process.env.PORT) || 8080;

// Settings come from environment variables, so the same code runs
// locally and in production with different values.
const GREETING = process.env.GREETING || "Hello";

// One JSON object per line. The Logs tab reads "severity" for the level.
function log(severity, message, fields = {}) {
  console.log(JSON.stringify({ severity, message, ...fields }));
}

const app = express();
app.use(express.json());

app.use((req, res, next) => {
  const started = Date.now();
  res.on("finish", () => {
    const severity = res.statusCode >= 500 ? "ERROR" : res.statusCode >= 400 ? "WARNING" : "INFO";
    log(severity, "request", { method: req.method, path: req.path, status: res.statusCode, ms: Date.now() - started });
  });
  next();
});

app.get("/", (req, res) => {
  res.json({ message: `${GREETING} from Express`, node: process.version });
});

app.get("/hello/:name", (req, res) => {
  res.json({ message: `${GREETING}, ${req.params.name}!` });
});

app.get("/health", (req, res) => {
  res.json({ status: "ok" });
});

app.use((req, res) => {
  res.status(404).json({ error: "Not found" });
});

app.use((err, req, res, next) => {
  log("ERROR", err.message, { path: req.path });
  res.status(500).json({ error: "Something went wrong" });
});

const server = app.listen(PORT, () => {
  log("INFO", `listening on port ${PORT}`);
});

// Light Cloud stops old instances with SIGTERM after a new version is live.
// Finish the requests in flight, then exit.
process.on("SIGTERM", () => {
  log("INFO", "SIGTERM received, shutting down");
  server.close(() => process.exit(0));
});

The three habits, in the code:

The port comes from PORT. In the cloud, the platform decides the port. A hard-coded port is the most common reason a Node.js app deploys but never answers.
Settings come from environment variables. GREETING is a stand-in for real settings such as an API key or a database address: the value lives on the platform, not in the code.
Logs are JSON with a severity. Each request is logged when it finishes, as INFO, WARNING for 4xx or ERROR for 5xx.

The SIGTERM handler is a small extra: when a new version goes live, the old instance gets a few seconds to finish what it is doing.

Step 3: Run it on your machine

Start the API in one terminal:

$ npm start
{"severity":"INFO","message":"listening on port 8080"}


PS> npm start
{"severity":"INFO","message":"listening on port 8080"}

Call it from a second terminal:

$ curl http://localhost:8080/hello/Ada
{"message":"Hello, Ada!"}
$ curl http://localhost:8080/nope
{"error":"Not found"}


PS> curl.exe http://localhost:8080/hello/Ada
{"message":"Hello, Ada!"}
PS> curl.exe http://localhost:8080/nope
{"error":"Not found"}

The first terminal now shows one log line per request, the second as a warning:

{"severity":"INFO","message":"request","method":"GET","path":"/hello/Ada","status":200,"ms":1}
{"severity":"WARNING","message":"request","method":"GET","path":"/nope","status":404,"ms":1}

Stop the API with Ctrl+C.

Step 4: Push it to GitHub

$ git init -b main
$ git add -A
$ git commit -m "Express API with PORT, env vars and JSON logs"
# Create an empty repository named tutorial-express-api on github.com/new first.
$ git remote add origin https://github.com/YOUR-USERNAME/tutorial-express-api.git
$ git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-express-api.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.


PS> git init -b main
PS> git add -A
PS> git commit -m "Express API with PORT, env vars and JSON logs"
# Create an empty repository named tutorial-express-api on github.com/new first.
PS> git remote add origin https://github.com/YOUR-USERNAME/tutorial-express-api.git
PS> git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-express-api.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.

Step 5: Deploy it with an environment variable

In the Light Cloud console, click New... , then Deploy from GitHub.
Search for tutorial-express-api and click it.

Light Cloud shows Express / Backend and Runs on a server : unlike a static website, an API needs a running process, so it gets a container.

Open Advanced - build settings, environment variables, domain, scaling. Port is 8080. Light Cloud passes it to the app as PORT, which is exactly what server.js reads. Leave it as it is.

Under Environment variables , click Add variable. Enter GREETING as the name and Hi as the value.

Click Deploy and wait for Deployed (72 seconds in my run; a container takes longer than a static site). The URL card has the API's address:

Step 6: Call the live API

$ curl https://main-tutorial-express-api-yourworkspace.light-cloud.io/
{"message":"Hi from Express","node":"v22.23.3"}
$ curl https://main-tutorial-express-api-yourworkspace.light-cloud.io/hello/Ada
{"message":"Hi, Ada!"}


PS> curl.exe https://main-tutorial-express-api-yourworkspace.light-cloud.io/
{"message":"Hi from Express","node":"v22.23.3"}
PS> curl.exe https://main-tutorial-express-api-yourworkspace.light-cloud.io/hello/Ada
{"message":"Hi, Ada!"}

The greeting is now Hi: the value from the console, not the Hello fallback in the code.

The first request after a quiet period can take a few seconds (3.6 seconds in my run). With Min instances at 0 the API sleeps when nobody uses it, which keeps it free, and wakes on the next request. Cold starts, measured explains the trade-off.

Step 7: Change a setting without touching the code

Open the Settings tab of Production.
Next to Environment Variables , click Edit.
Change the value of GREETING to Welcome and click Save.

Saving redeploys the same commit with the new value. About a minute later (59 seconds in my run):

$ curl https://main-tutorial-express-api-yourworkspace.light-cloud.io/
{"message":"Welcome from Express","node":"v22.23.3"}


PS> curl.exe https://main-tutorial-express-api-yourworkspace.light-cloud.io/
{"message":"Welcome from Express","node":"v22.23.3"}

Step 8: Read the logs

Open the Logs tab. Every line your API printed is here, next to lines Light Cloud adds itself, such as GET https://.../nope 404 for each request:

Because the lines are JSON with a severity, each one has the right level: the request to /nope is a WARNING , the others are INFO. Click a line to open it. Everything else the API logged is under JSON Payload :

Two more lines are worth finding after Step 7: listening on port 8080 from the new instance, and SIGTERM received, shutting down from the old one. That is the graceful shutdown from Step 2 at work.

To see only problems, set the level filter to warnings and above.

Troubleshooting

The deploy fails: container failed to start and listen on the port

The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable within the allocated timeout.

The app listens on a fixed port instead of PORT. I tried it with app.listen(3000): the deploy failed after about four minutes, and the previous version kept serving the whole time. Read the port with Number(process.env.PORT) || 8080, commit and push. If your app must use another port, set Port under Advanced to match instead.

The deploy fails in the build step with npm ci

npm ci needs a package-lock.json that matches package.json. Run npm install on your machine, commit package-lock.json and push again.