DEV Community: Julia

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.

Deploy a SvelteKit Site as Static Files: adapter-static and Prerendering

Julia — Sat, 03 Oct 2026 09:00:00 +0000

To deploy a SvelteKit site on Light Cloud as static files, create it with adapter-static, add export const prerender = true to src/routes/+layout.ts, push it to GitHub and click Deploy in the console. Light Cloud detects SvelteKit and adapter-static, runs npm run build and serves the build folder from the edge. Each page is a real HTML file, so /about opened directly shows the About page.

In my run the deploy took 30 seconds.

What you will build

A two-page SvelteKit site, Home and About, prerendered to HTML at build time and live on a light-cloud.io address. It follows the visitor's light or dark system setting.

Live demo: main-tutorial-sveltekit-app-examples.light-cloud.io. Source code: github.com/light-cloud-com/tutorial-sveltekit-app.

Static or server: which adapter?

SvelteKit builds for a target through an adapter. The two that matter here:

adapter-static builds every page to HTML ahead of time. Nothing runs on a server; the files are served from the edge. Good for sites, docs, blogs and portfolios, and it runs on the free plan. This guide uses it.
adapter-node builds a Node.js server that renders pages on each request. You need it for form actions, server load functions that read per-visitor data, or API routes. On Light Cloud that runs as a container.

If you are not sure, start static. Moving to adapter-node later is a change of adapter, not a rewrite.

Before you start

Node.js 20.19 or later, or 22.12 or later (what Vite 8 requires); I used Node.js 24.
Git and a GitHub account.
A free Light Cloud account at console.light-cloud.com with GitHub connected.
On Windows, use PowerShell 7. The last check uses curl (on Windows, curl.exe, which ships with Windows 10 and 11).

Step 1: Create the SvelteKit app

The Svelte CLI, sv, can add adapter-static while it creates the project:

$ npx sv@latest create tutorial-sveltekit-app --template minimal --types ts --add sveltekit-adapter="adapter:static" --install npm
┌ Welcome to the Svelte CLI! (v0.17.1)
│
◆ Project created
│
◆ Successfully setup add-ons: sveltekit-adapter
│
◆ Successfully installed dependencies with npm
│
└ You're all set!


PS> npx sv@latest create tutorial-sveltekit-app --template minimal --types ts --add sveltekit-adapter="adapter:static" --install npm
┌ Welcome to the Svelte CLI! (v0.17.1)
│
◆ Project created
│
◆ Successfully setup add-ons: sveltekit-adapter
│
◆ Successfully installed dependencies with npm
│
└ You're all set!

--template minimal gives an almost empty site and --types ts sets up TypeScript. Output is trimmed.

Looking for svelte.config.js? New projects no longer have one. The adapter is set in vite.config.ts:

import adapter from '@sveltejs/adapter-static';
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
    plugins: [
        sveltekit({
            compilerOptions: {
                // Force runes mode for the project, except for libraries. Can be removed in svelte 6.
                runes: ({ filename }) => filename.split(/[/\\]/).includes('node_modules') ? undefined : true
            },
            adapter: adapter()
        })
    ]
});

Step 2: Turn on prerendering

adapter-static can only publish pages that were built ahead of time, and SvelteKit does not prerender by default. Build the new project as it is and it stops with Error: Encountered dynamic routes (the full message is under Troubleshooting).

One line fixes it for the whole site. Create this file:

export const prerender = true;

Step 3: Add the pages

A shared layout with two links and a few styles. color-scheme: light dark lets the browser follow the visitor's system theme:

<script lang="ts">
    import { page } from '$app/state';
    import favicon from '$lib/assets/favicon.svg';

    let { children } = $props();
</script>

<svelte:head>
    <link rel="icon" href={favicon} />
</svelte:head>

<nav>
    <a href="https://blog.light-cloud.com/" aria-current={page.url.pathname === '/' ? 'page' : undefined}>Home</a>
    <a href="https://blog.light-cloud.com/about" aria-current={page.url.pathname === '/about' ? 'page' : undefined}>About</a>
</nav>

<main>
    {@render children()}
</main>

<style>
    :global(:root) {
        color-scheme: light dark;
        font-family: system-ui, sans-serif;
    }

    :global(body) {
        max-width: 40rem;
        margin: 0 auto;
        padding: 2rem 1rem;
    }

    nav {
        display: flex;
        gap: 1rem;
        margin-bottom: 2rem;
    }

    a {
        color: light-dark(#d93a00, #ff8a4c);
    }

    a[aria-current='page'] {
        font-weight: 600;
        text-decoration: none;
    }
</style>

Replace the starter home page:

<svelte:head>
    <title>Home</title>
</svelte:head>

<h1>Hello from Light Cloud</h1>
<p>A SvelteKit site, prerendered with adapter-static.</p>

In SvelteKit a folder is a route, so the About page lives in an about folder:

<svelte:head>
    <title>About</title>
</svelte:head>

<h1>About</h1>
<p>This page was prerendered to HTML at build time and is served from the edge.</p>

Step 4: Run it and build it

$ npm run dev
  VITE v8.3.1 ready in 441 ms

  ➜ Local: http://localhost:5173/
$ npm run build
✓ built in 974ms
> Using @sveltejs/adapter-static
  Wrote site to "build"
  ✔ done
$ ls build
_app
about.html
index.html
robots.txt


PS> npm run dev
  VITE v8.3.1 ready in 441 ms

  ➜ Local: http://localhost:5173/
PS> npm run build
✓ built in 974ms
> Using @sveltejs/adapter-static
  Wrote site to "build"
  ✔ done
PS> Get-ChildItem build -Name
_app
about.html
index.html
robots.txt

Open http://localhost:5173, click between the two pages, then stop the server with Ctrl+C before you build. Build output is trimmed.

The build folder is the whole site: one HTML file per page, plus the JavaScript in _app that makes links switch pages without a reload.

Step 5: Push it to GitHub

$ git init -b main
$ git add -A
$ git commit -m "SvelteKit site with adapter-static"
# Create an empty repository named tutorial-sveltekit-app on github.com/new first.
$ git remote add origin https://github.com/YOUR-USERNAME/tutorial-sveltekit-app.git
$ git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-sveltekit-app.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 "SvelteKit site with adapter-static"
# Create an empty repository named tutorial-sveltekit-app on github.com/new first.
PS> git remote add origin https://github.com/YOUR-USERNAME/tutorial-sveltekit-app.git
PS> git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-sveltekit-app.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.

The project's .gitignore already keeps node_modules, .svelte-kit and build out of Git.

Step 6: Deploy it

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

Light Cloud shows SvelteKit and, in the reasons, adapter-static , with Served from the edge. It found adapter-static in package.json, so it deploys the site as static files rather than as a server.

Optional: under Advanced - build settings, environment variables, domain, scaling you can see npm ci, npm run build and the output directory build. Nothing to change.

Click Deploy and wait for Deployed (30 seconds in my run). Open the address from the URL card:

From now on, every push to main redeploys the site by itself.

Step 7: Open a page directly

Open https://main-tutorial-sveltekit-app-yourworkspace.light-cloud.io/about in a new tab, or refresh the page while on About. Light Cloud serves about.html for /about, so the page comes straight from the prerendered file:

To see that the page really comes prerendered, right-click it and choose View Page Source : the HTML already contains <h1>About</h1>, before any JavaScript runs.

/about/ with a trailing slash works too. A path with no page, such as /nope, falls back to index.html.

Troubleshooting

Error: Encountered dynamic routes

@sveltejs/adapter-static: all routes must be fully prerenderable, but found the following routes that are dynamic:
  - src/routes/
error during build:
Error: Encountered dynamic routes

Prerendering is off. Add export const prerender = true; to src/routes/+layout.ts (Step 2), build again, commit and push.

Regulators vs. the Duopoly

Julia — Fri, 02 Oct 2026 13:56:08 +0000

On March 31, 2026, the UK's Competition and Markets Authority drew a line under its three-year cloud investigation, accepting voluntary commitments from AWS and Microsoft on egress fees and interoperability. The mountain labored for three years, produced findings that "competition is not working well", recommended the strongest tool in its new kit, and then delivered a memorandum of understanding.

That arc is worth studying, not mocking, because the CMA case is the cleanest specimen we have of the question this post is about: when regulators finally move against cloud concentration, which remedies change anything real, and which are theater performed for the annual report? My scorecard, argued below: portability mandates and licensing interventions are real, egress concessions are a fee that died years ago wearing a medal, and the credible threat that got traded away was the only thing the duopoly actually feared.

Three years in four beats

Beat one: the CMA's investigation found the structural problems everyone suspected: AWS and Microsoft each holding roughly 30-40% of the UK market, egress fees and technical barriers suppressing switching, and Microsoft's software licensing practices tilting the field against rivals running its products. Beat two: the final decision in July 2025 recommended designating both companies with strategic market status under the Digital Markets, Competition and Consumers Act, the UK's new regime for binding, tailored conduct rules. Beat three: March 2026, the SMS route was shelved in favor of the voluntary commitments. Beat four, and the one to watch: a separate SMS investigation into Microsoft's software licensing spun up regardless, aimed at the practice the findings called out most sharply.

The UK case carries weight beyond the UK, which is why the shelving mattered. The DMCCA regime was built specifically to move faster than classic competition law, other regulators are watching its first outings the way case law gets watched, and the cloud investigation was its most prominent test. A debut that ends in voluntary undertakings teaches every watching authority, and every watched company, what the new powers cost to invoke. Precedents about hesitation travel as far as precedents about action.

Sorting the remedies

Run each remedy through one test: does it change what a customer can do, or what a vendor must say?

Egress commitments fail the test instantly, and we've written the obituary already: exit egress died globally in 2024 under EU Data Act pressure, so promising a regulator the corpse stays dead costs the duopoly nothing and headlines beautifully. It's the pattern from that post repeating at regulatory scale: concessions cluster on the locks vendors stopped defending, never on the ones doing the holding. The same sorting works on any jurisdiction's package, which is the reason to learn it once: the EU's Data Act portability rules pass the test because they changed what a customer can do with their feet, while a dozen codes of conduct since have failed it politely.

Interoperability commitments are contingent: real if they arrive with technical specificity, deadlines, and someone with authority to measure compliance; theater if they stay at the altitude of "committed to open standards", which is where voluntary undertakings historically retire. The licensing intervention is the real one, and the CMA's own sequencing admits it, because licensing is where the findings located actual harm, and licensing is precisely what got carved out for the binding-powers track rather than the handshake track. And the SMS designation itself was the remedy that mattered most by never being used: the threat of tailored, enforceable conduct rules is what brought voluntary offers to the table at all. Trading it away converts a bargaining position into paper, and the price of that trade will be visible in how the commitments age.

The steelman: the handshake might be right

The defense of the CMA's choice is better than it looks. Voluntary commitments arrive in months; SMS designations arrive after years of process and litigation, against opponents with infinite legal budgets, under a regime so new it has no case law, and regulatory humility about untested powers is a virtue, not cowardice. There's also a genuine question of timing: between the Data Act, DORA's exit requirements, and the unbundling the market did on its own, a lot of what a 2023 remedy would have targeted has already moved. Regulate the market you have, not the one your case opened against.

Concede the speed argument whole. The answer is that speed and credibility aren't the same axis: a fast remedy with no enforcement mechanism is just fast, and the entire history of voluntary undertakings in tech is a history of compliance narrowing to the letter while the practice regrows around it. The honest verdict on the CMA case won't be available until the licensing probe shows whether the binding track has teeth. That's the scoreboard to watch, and it's refreshingly concrete: either Microsoft's licensing terms for rivals change in measurable ways by 2027, or the UK's shiny new digital markets regime met the duopoly and blinked.

For everyone downstream, the practical reading is the one this blog keeps arriving at from every direction: regulation will occasionally hand you a right, and rights you can't exercise are decor. The Data Act gave you free exit; portability is what makes it usable. The CMA may yet fix licensing; your architecture decides whether you could act on the fix. Regulators move in years and blink under pressure. Your exit plan doesn't have to do either. Which one are you betting on?

How to Deploy an Angular App on Light Cloud, Deep Links Included

Julia — Fri, 02 Oct 2026 09:00:00 +0000

To deploy an Angular app on Light Cloud, push it to GitHub, choose Deploy from GitHub in the console and click Deploy. Light Cloud detects Angular, reads angular.json to find the nested build folder (dist/<project name>/browser), runs npm ci and npm run build, and serves the result from the edge. Angular Router deep links such as /about work without any redirect rules.

In my run the first deploy took 41 seconds, and a pushed change was live about a minute after git push.

What you will build

A small Angular app with two pages, Home and About, linked with Angular Router and live on a light-cloud.io address. It follows the visitor's light or dark system setting.

Live demo: main-tutorial-angular-website-examples.light-cloud.io. Source code: github.com/light-cloud-com/tutorial-angular-website.

Before you start

Node.js 22.22.3 or later, or 24.15.0 or later. This is what the Angular CLI 22.2 requires; I used Node.js 24.
Git and a GitHub account.
A free Light Cloud account at console.light-cloud.com with GitHub connected.
On Windows, use PowerShell 7. The last check uses curl (on Windows, curl.exe, which ships with Windows 10 and 11).

New to deploying from GitHub? The React guide walks through the same console screens in more detail.

Step 1: Create the Angular app

--defaults accepts the recommended answers without asking, and --ssr=false keeps the app static, with no server-side rendering:

$ npx @angular/cli@latest new tutorial-angular-website --defaults --ssr=false
CREATE tutorial-angular-website/angular.json (1957 bytes)
CREATE tutorial-angular-website/package.json (800 bytes)
CREATE tutorial-angular-website/src/main.ts (222 bytes)
CREATE tutorial-angular-website/src/app/app.ts (307 bytes)
CREATE tutorial-angular-website/src/app/app.routes.ts (77 bytes)
✔ Packages installed successfully.
    Successfully initialized git.


PS> npx @angular/cli@latest new tutorial-angular-website --defaults --ssr=false
CREATE tutorial-angular-website/angular.json (1957 bytes)
CREATE tutorial-angular-website/package.json (800 bytes)
CREATE tutorial-angular-website/src/main.ts (222 bytes)
CREATE tutorial-angular-website/src/app/app.ts (307 bytes)
CREATE tutorial-angular-website/src/app/app.routes.ts (77 bytes)
✔ Packages installed successfully.
    Successfully initialized git.

Output is trimmed; the CLI lists every file it creates. It also installs the packages and makes the first Git commit for you.

Step 2: Run it and build it once

$ cd tutorial-angular-website
$ npm start
Watch mode enabled. Watching for file changes...
  ➜ Local: http://localhost:4200/
$ npm run build
Initial chunk files | Names | Raw size | Estimated transfer size
main-AMMXP5ZW.js | main | 218.81 kB | 59.99 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes

Application bundle generation complete. [1.918 seconds]

Output location: /Users/you/tutorial-angular-website/dist/tutorial-angular-website


PS> cd tutorial-angular-website
PS> npm start
Watch mode enabled. Watching for file changes...
  ➜ Local: http://localhost:4200/
PS> npm run build
Initial chunk files | Names | Raw size | Estimated transfer size
main-AMMXP5ZW.js | main | 218.81 kB | 59.99 kB
styles-5INURTSO.css | styles | 0 bytes | 0 bytes

Application bundle generation complete. [1.918 seconds]

Output location: C:\Users\you\tutorial-angular-website\dist\tutorial-angular-website

Open http://localhost:4200 to see the Angular starter page, then stop the server with Ctrl+C before you build. Output is trimmed.

Look at the output location: the site's files end up one level deeper, in dist/tutorial-angular-website/browser. That nested folder is the one a host must publish, and it is the most common reason an Angular deploy shows a blank page elsewhere. Light Cloud finds it for you in Step 4.

Step 3: Push it to GitHub

The Angular CLI already created the repository and the first commit, so one command creates the GitHub repository and pushes:

# Create an empty repository named tutorial-angular-website on github.com/new first.
$ git remote add origin https://github.com/YOUR-USERNAME/tutorial-angular-website.git
$ git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-angular-website.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.


# Create an empty repository named tutorial-angular-website on github.com/new first.
PS> git remote add origin https://github.com/YOUR-USERNAME/tutorial-angular-website.git
PS> git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-angular-website.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.

The branch is named after your Git setting init.defaultBranch. If yours is master, that is fine; Light Cloud deploys whichever branch the repository uses.

Step 4: Deploy it

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

Light Cloud shows Angular / Frontend and Served from the edge. The banner also lists what it read from angular.json: Custom output: dist/tutorial-angular-website/browser.

Optional: open Advanced - build settings, environment variables, domain, scaling. The Output directory already holds the nested folder, next to npm ci and npm run build. Nothing to change.

Click Deploy and wait for Deployed (41 seconds in my run). Open the address from the URL card:

Step 5: Add a second page with Angular Router

The starter has a router but no routes. Generate two page components:

$ npx ng generate component home
CREATE src/app/home/home.css (0 bytes)
CREATE src/app/home/home.spec.ts (518 bytes)
CREATE src/app/home/home.ts (177 bytes)
CREATE src/app/home/home.html (19 bytes)
$ npx ng generate component about
CREATE src/app/about/about.css (0 bytes)
CREATE src/app/about/about.spec.ts (525 bytes)
CREATE src/app/about/about.ts (181 bytes)
CREATE src/app/about/about.html (20 bytes)


PS> npx ng generate component home
CREATE src/app/home/home.css (0 bytes)
CREATE src/app/home/home.spec.ts (518 bytes)
CREATE src/app/home/home.ts (177 bytes)
CREATE src/app/home/home.html (19 bytes)
PS> npx ng generate component about
CREATE src/app/about/about.css (0 bytes)
CREATE src/app/about/about.spec.ts (525 bytes)
CREATE src/app/about/about.ts (181 bytes)
CREATE src/app/about/about.html (20 bytes)

Give each page a path. title sets the browser tab title:

import { Routes } from '@angular/router';
import { About } from './about/about';
import { Home } from './home/home';

export const routes: Routes = [
  { path: '', component: Home, title: 'Home' },
  { path: 'about', component: About, title: 'About' },
];

Replace the whole starter page with two links and the router outlet, where the current page appears:

<nav>
  <a routerLink="/" routerLinkActive="active" [routerLinkActiveOptions]="{ exact: true }">Home</a>
  <a routerLink="/about" routerLinkActive="active">About</a>
</nav>
<main>
  <router-outlet />
</main>

The links need RouterLink and RouterLinkActive in the component's imports:

import { Component } from '@angular/core';
import { RouterLink, RouterLinkActive, RouterOutlet } from '@angular/router';

@Component({
  imports: [RouterOutlet, RouterLink, RouterLinkActive],
  selector: 'app-root',
  styleUrl: './app.css',
  templateUrl: './app.html',
})
export class App {}

Write the two pages:

<h1>Hello from Light Cloud</h1>
<p>An Angular app built with the Angular CLI and served from the edge.</p>


<h1>About</h1>
<p>This page lives at /about. Open it directly or refresh it, and Angular Router still shows it.</p>

And a few global styles. color-scheme: light dark lets the browser follow the visitor's system theme:

:root {
  color-scheme: light dark;
  font-family: system-ui, sans-serif;
}

body {
  max-width: 40rem;
  margin: 0 auto;
  padding: 2rem 1rem;
}

nav {
  display: flex;
  gap: 1rem;
  margin-bottom: 2rem;
}

a {
  color: light-dark(#c3002f, #ff6b8b);
}

a.active {
  font-weight: 600;
  text-decoration: none;
}

Check it with npm start, then commit and push:

$ git add -A
$ git commit -m "Add Home and About pages with Angular Router"
$ git push


PS> git add -A
PS> git commit -m "Add Home and About pages with Angular Router"
PS> git push

Deploy on push is on by default, so Light Cloud builds the new version by itself. The Deployments tab lists it as deployed by GitHub Auto-Deploy :

In my run the new pages were live about a minute after git push.

The starter's test in src/app/app.spec.ts still looks for the old heading, so npx ng test now fails. The deploy does not run tests, but the repository has the updated test if you want it green.

Step 6: Open a deep link

Angular Router uses real-looking paths such as /about. There is no about file in the build, so on many static hosts opening that address directly returns a 404. On Light Cloud any path that is not a file is answered with index.html, and Angular Router shows the right page.

Open https://main-tutorial-angular-website-yourworkspace.light-cloud.io/about directly, or refresh the page while on About:

Troubleshooting

The Angular CLI requires a minimum Node.js version

Node.js version v22.16.0 detected.
The Angular CLI requires a minimum Node.js version of v22.22.3 or v24.15.0 or v26.0.0.

Your Node.js is older than Angular 22 needs. Install a current Node.js 22 or 24 from nodejs.org and run the command again.

The site shows a blank page or "Not found"

The Output directory does not point at the folder with index.html. For the Angular CLI it is dist/<project name>/browser. If you renamed the project in angular.json or set your own outputPath, open Production , then the Settings tab, click Edit next to Build Settings , correct the Output directory and redeploy.

Deploy a React App in Minutes: Your First Light Cloud Website, for Free

Julia — Wed, 30 Sep 2026 09:00:00 +0000

To deploy a React app on Light Cloud, push your project to GitHub, choose Deploy from GitHub in the console, pick the repository and click Deploy. Light Cloud detects React from package.json, runs npm ci and npm run build, and serves the dist folder from the edge at an HTTPS address. It works on the free plan, and every later git push redeploys the site by itself.

In my run the first build took 15 seconds, and an update was live 50 seconds after git push.

What you will build

A React website made with the official Vite starter, live on its own light-cloud.io address, then updated with one pushed change.

Live demo: main-tutorial-react-website-examples.light-cloud.io. Source code: github.com/light-cloud-com/tutorial-react-website.

Before you start

Node.js 20.19 or later, or 22.12 or later (what Vite requires); I used Node.js 22.16.
Git and a GitHub account.
A free Light Cloud account at console.light-cloud.com, with GitHub connected. The console asks you to connect it the first time you choose Deploy from GitHub.
On Windows, run the commands in PowerShell 7.

Step 1: Create the React app

Vite's starter gives you a working React app in one command:

$ npm create vite@latest tutorial-react-website -- --template react --no-interactive
◇ Scaffolding project in /Users/you/tutorial-react-website...
└ Done. Now run:

  cd tutorial-react-website
  npm install
  npm run dev


PS> npm create vite@latest tutorial-react-website -- --template react --no-interactive
◇ Scaffolding project in C:\Users\you\tutorial-react-website...
└ Done. Now run:

  cd tutorial-react-website
  npm install
  npm run dev

--template react picks React with JavaScript (use react-ts for TypeScript) and --no-interactive skips the questions. Output is trimmed; the path shows your own folder.

Step 2: Run it on your machine

Install the dependencies and start the development server:

$ cd tutorial-react-website
$ npm install
found 0 vulnerabilities
$ npm run dev

  VITE v8.3.1 ready in 487 ms

  ➜ Local: http://localhost:5173/


PS> cd tutorial-react-website
PS> npm install
found 0 vulnerabilities
PS> npm run dev

  VITE v8.3.1 ready in 487 ms

  ➜ Local: http://localhost:5173/

Open http://localhost:5173 and you should see the starter page. Your Vite version may be newer. Stop the server with Ctrl+C.

Step 3: Push it to GitHub

Light Cloud deploys from a Git repository. Commit the project, create an empty repository on GitHub, and push to it:

$ git init -b main
$ git add -A
$ git commit -m "React website from the Vite starter"
# Create an empty repository named tutorial-react-website on github.com/new first.
$ git remote add origin https://github.com/YOUR-USERNAME/tutorial-react-website.git
$ git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-react-website.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 "React website from the Vite starter"
# Create an empty repository named tutorial-react-website on github.com/new first.
PS> git remote add origin https://github.com/YOUR-USERNAME/tutorial-react-website.git
PS> git push -u origin main
To https://github.com/YOUR-USERNAME/tutorial-react-website.git
 * [new branch] main -> main
branch 'main' set up to track 'origin/main'.

Leave the new repository empty (no README), so the push goes through. The starter's .gitignore already keeps node_modules and dist out of Git.

Step 4: Deploy from GitHub

In the Light Cloud console, click New... at the top of the sidebar, then Deploy from GitHub.

Type the repository name into Search your repositories... and click it. A new repository can take a few seconds to appear.

Light Cloud reads the repository and shows what it found: React / Frontend , based on package.json and package-lock.json, Served from the edge. A React app compiles to static files, so no server runs for it; the files are delivered from a content delivery network.

Optional: open Advanced - build settings, environment variables, domain, scaling to see what Light Cloud will run. It has already filled in npm ci as the Install command , npm run build as the Build command and dist as the Output directory. You do not need to change anything.

Click Deploy.

Step 5: Open your site

When Production shows Deployed (15 seconds in my run), open it. The URL card on the Overview tab links to your site:

The address follows the pattern https://main-<app name>-<workspace>.light-cloud.io, and HTTPS is already set up.

Step 6: Update the site with git push

Change the headline in src/App.jsx:

<h1>Hello from Light Cloud</h1>

Commit and push:

$ git commit -am "Change the headline"
$ git push


PS> git commit -am "Change the headline"
PS> git push

That is all. Deploy on push is on by default, so Light Cloud builds the new version when GitHub tells it about the push. The Deployments tab lists it as deployed by GitHub Auto-Deploy :

In my run the new headline was live 50 seconds after git push.

Step 7: Check that client-side routes work

If you add React Router later, pages like /about only exist in the browser. Light Cloud answers any path that is not a real file with your index.html, so those links work when opened directly or refreshed:

To try it now, open https://main-tutorial-react-website-yourworkspace.light-cloud.io/about/team, a page that does not exist yet. Instead of a 404 error, you get the home page: that is index.html, where React Router would take over.

Troubleshooting

The repository does not appear in the search

The Light Cloud GitHub App does not have access to it yet. Click Add or configure an account under the search box and grant access to the repository (or to all repositories). A repository created a moment ago can also take a few seconds to show up.

The build fails with "npm ci can only install packages when your package.json and package-lock.json are in sync"

Run npm install on your machine, commit the updated package-lock.json and push again.

What "Open" Means After HashiCorp

Julia — Wed, 30 Sep 2026 08:22:35 +0000

In August 2023, HashiCorp swapped Terraform's license from the Mozilla Public License to the Business Source License, and thousands of engineering teams discovered simultaneously that a load-bearing piece of their infrastructure had changed its legal nature overnight, without a version bump, without a migration guide, without asking. The code was identical the next morning. The deal was not.

What followed is now a complete story with a beginning, middle, and instructive end: the community forked, the fork survived, and the company got acquired anyway, by IBM, for $6.4 billion, closing February 27, 2025. This post is about what that story settled. My claim: after HashiCorp, license risk belongs in the same planning category as provider outages and vendor acquisitions, because "open source" turned out to describe a current state rather than a commitment, and the difference between those two things is your exposure.

The timeline, compressed

The BSL's mechanics matter more than its reputation. It's not a rug-pull to proprietary: source stays visible, most end users remain unaffected, and each release converts back to open source after four years. What it restricts is use "in a competitive way" with HashiCorp's own offerings, which is to say it was a targeted strike at the vendors building commercial products on Terraform. Precise, defensible, and quietly radical, because it demonstrated that a license everyone had treated as ground truth was actually a policy, revisable by whoever holds the copyright.

The community's answer arrived within weeks: a coalition forked Terraform 1.5, the last MPL release, and OpenTofu went to the Linux Foundation with commercial backers whose businesses depended on the fork existing. Then the ending nobody's talking point predicted: IBM bought the whole company. The BSL didn't block the acquisition or get reversed by it; instead the license question acquired a second layer, because now the copyright that can rewrite the deal sits inside a portfolio strategy nobody outside Armonk controls.

What the fork actually proved

Forks were always open source's constitutional theory: the community's right of exit, the reason single-vendor control was supposedly tolerable. Theory, mostly, because executed forks that thrive are rare; forking is expensive, thankless, and usually starves. OpenTofu is the counterexample that matters precisely because it worked: foundation governance, real releases, real adoption, vendors funding it out of existential need rather than idealism.

But look at the conditions that made it work, because they're the actual checklist. A permissive license existed to fork from. The affected parties were companies with revenue, not volunteers with weekends. The project's surface area was forkable by a small expert group. And a neutral foundation stood ready to hold the keys. Remove any one of those and the constitutional theory reverts to theory, which is exactly the audit you should run on every load-bearing dependency you have: not "is it open today" but "if the deal changed tomorrow, does a credible fork coalition exist, and would we be in it or waiting on it?"

Depending on VC-backed open source without getting burned

The structural fact underneath all of this is unglamorous: a venture-backed company whose product is open source has promised its investors an outcome, and the commons it built is the asset it will eventually monetize harder. That's not cynicism; it's the deal working as designed, and it has a small set of endings, relicense, acquisition, or both. HashiCorp did both. Pretending otherwise is how teams end up surprised by events that were structurally predictable the day the Series C closed.

So read the boring documents before you build on the shiny repo. Who holds the trademark and the copyright, one company or a foundation? Does a contributor license agreement concentrate relicensing power? What does the license convert to, and when? Is governance a committee or a courtesy? None of this appears in the quickstart, all of it determines what happens to you in year four, and the graph-versus-text argument we've made about infrastructure applies to its legal layer too: the dependency structure you can't see is the one that gets you.

The steelman: HashiCorp had a point

The uncomfortable case for the relicense deserves its space. Building commercial products on someone else's open source while contributing little back is legal free-riding, hyperscalers industrialized it, and a company watching others monetize its R&D isn't paranoid to respond. The BSL genuinely spared end users. MongoDB and Elastic walked similar roads and their businesses survived, their ecosystems adapted, and some of their forks even made the original vendors sharper. If open source companies can't capture value, the argument goes, there will eventually be less open source, and everyone loses slower but loses.

Most of that stands. What doesn't survive is the conclusion that nothing changed for the people downstream. The old equilibrium let you treat a license as terrain, fixed, walkable, boring; the new one requires treating it as weather. Both are livable. Only one of them is what a decade of "just use the open source tool" advice assumed, and infrastructure teams got moved from the first world to the second without a memo. The memo is what this post is for.

The operational conclusion fits in a sentence: depend on open source exactly as much as you like, and know your exit the way regulators now make banks know theirs. A fork you could join, a compatible alternative you've tested, an abstraction that makes the tool swappable, any of these converts a relicense from crisis to changelog. Which of your load-bearing dependencies could rewrite its deal tomorrow, and do you know your answer, or just your hope?

Microservices Part 6: Trace One Request Through the Logs

Julia — Tue, 29 Sep 2026 09:00:00 +0000

To follow one request across microservices on Light Cloud, give it an ID, pass that ID to every service in an x-request-id header, and print it in every log line as JSON with a severity field. Then search each service's Logs tab for the ID: every line the request produced appears, in every service, and the level filter narrows the view to warnings and errors.

This is Part 6, the last part of the series. It uses Bean There from Part 1, where the request ID was already built in.

What you will build

Log lines that the Logs tab understands: JSON with severity, service, requestId and a message.
A traced order: one ID, found in orders-api and in catalog-api.
A traced failure: an order for a product that does not exist, found with the warnings and above filter.

Source code: github.com/light-cloud-com/tutorial-microservices, tag part-6.

Before you start

Bean There from Parts 1 to 5.
A terminal with curl (on Windows, curl.exe in PowerShell 7) and Git.

Step 1: Get the Part 6 code

Sync your fork or pull, as in the earlier parts:

$ git pull upstream main
$ git push origin main


PS> git pull upstream main
PS> git push origin main

Both APIs changed, so both redeploy.

Step 2: How the request ID travels

Each API gives every request an ID, or keeps the one the caller sent, and returns it in the response. orders-api passes it on when it calls catalog-api:

@app.middleware("http")
async def request_id(request: Request, call_next):
    request.state.request_id = request.headers.get("x-request-id") or str(uuid.uuid4())
    response = await call_next(request)
    response.headers["x-request-id"] = request.state.request_id
    return response


reply = await client.post(
    f"{CATALOG_API_URL}/internal/products/{order.product_id}/reserve",
    json={"quantity": order.quantity},
    headers={"x-internal-secret": INTERNAL_SECRET, "x-request-id": request_id},
)

catalog-api does the same on its side, keeping the ID it receives:

app.use((req, res, next) => {
  req.requestId = req.get("x-request-id") || randomUUID();
  res.set("x-request-id", req.requestId);
  next();
});

Step 3: Write logs the Logs tab understands

Part 6 adds a severity field to every log line. The Logs tab reads it: lines get the right level and colour, and the level filter works. Without it, a line shows as DEFAULT.

// One JSON object per line. "severity" is what the Logs tab's level filter
// reads (INFO, WARNING, ERROR); requestId ties lines from all services together.
function log(req, message, extra = {}, severity = "INFO") {
  console.log(JSON.stringify({ severity, service: "catalog-api", requestId: req.requestId, message, ...extra }));
}


def log(request_id: str, message: str, severity: str = "INFO", **extra):
    print(json.dumps({"severity": severity, "service": "orders-api", "requestId": request_id, "message": message, **extra}), flush=True)

Part 6 also fixes a bug from earlier parts: an order for a product that does not exist used to answer "Not enough stock". It now returns 404 Product not found and logs a warning in both services.

Step 4: Send a traced order

Place an order with an ID you choose, so it is easy to find. -i shows the response headers, including the ID coming back:

$ curl -s -i -X POST https://main-orders-api-yourworkspace.light-cloud.io/orders \
  -H "content-type: application/json" -H "x-request-id: order-7f3a" \
  -d '{"product_id":2,"quantity":1}'
HTTP/2 201
x-request-id: order-7f3a

{"id":9,"product":"Pour-over kettle","quantity":1,"total_cents":5900}


PS> curl.exe -s -i -X POST https://main-orders-api-yourworkspace.light-cloud.io/orders `
  -H "content-type: application/json" -H "x-request-id: order-7f3a" `
  -d '{"product_id":2,"quantity":1}'
HTTP/2 201
x-request-id: order-7f3a

{"id":9,"product":"Pour-over kettle","quantity":1,"total_cents":5900}

Other headers are left out here. Your order id will differ. In a real app the browser would not choose the ID; the first service creates one, and you find it in the response or in the first log line.

Step 5: Find it in both services

Open orders-api , Production , then the Logs tab.
Type the ID, order-7f3a, into search lines and press Enter.

Two lines: placing order and order placed. Click a line to open it. Under JSON Payload you see every field the service logged, including the requestId:

Now open catalog-api , Production , Logs , and search for the same ID.

reserved stock: the same request, one service further along. Together the two searches show the order's whole path, in order, with timestamps.

Step 6: Find failures with the level filter

Send an order that fails:

$ curl -s -i -X POST https://main-orders-api-yourworkspace.light-cloud.io/orders \
  -H "content-type: application/json" -H "x-request-id: order-404b" \
  -d '{"product_id":999,"quantity":1}'
HTTP/2 404
x-request-id: order-404b

{"detail":"Product not found"}


PS> curl.exe -s -i -X POST https://main-orders-api-yourworkspace.light-cloud.io/orders `
  -H "content-type: application/json" -H "x-request-id: order-404b" `
  -d '{"product_id":999,"quantity":1}'
HTTP/2 404
x-request-id: order-404b

{"detail":"Product not found"}

Now find it without knowing the ID. In orders-api's Logs tab, clear the search, open the level filter and choose warnings and above :

Only warnings and errors remain. Open order for unknown product to see which product and which request:

Two kinds of lines show up. Your own order for unknown product warning, and a line Light Cloud writes for every HTTP request, here POST https://main-orders-api-yourworkspace.light-cloud.io/orders 404. Requests that end with a 4xx status are marked WARNING automatically, so this filter finds failed requests even in a service that logs nothing itself. With the requestId from the payload you can now search catalog-api for the other half of the story.

Microservices Part 5: Preview a Branch and Roll Back

Julia — Mon, 28 Sep 2026 09:00:00 +0000

To ship a change to one microservice without breaking the others on Light Cloud, push it to a Git branch: Light Cloud deploys the branch to its own URLs, posts the preview links on your pull request, and after the merge redeploys only the services the change touched. If a bad deploy still reaches production, Rollback on the Deployments tab serves an earlier build again; in my test the service was fixed in 13 seconds.

This is Part 5 of the series, on the Bean There shop from Part 1. Deploy every branch and Remove stale environments were switched on when the apps were created, which is the default.

What you will build

A feature, "stock status" ("in stock", "low", "sold out"), that changes catalog-api and the web app.
A full preview of the feature on branch URLs, wired so the preview shop talks to the preview APIs.
A merged pull request, and then a deliberate bug in production that you roll back and revert.

Source code: github.com/light-cloud-com/tutorial-microservices, tag part-5.

Before you start

Bean There from Parts 1 to 4, deployed from your fork.
Git and a terminal with curl (on Windows, curl.exe in PowerShell 7).

Step 1: Push a feature branch

Create a branch and change catalog-api so /products also returns a stock_status:

$ git checkout -b feature/stock-status
Switched to a new branch 'feature/stock-status'


PS> git checkout -b feature/stock-status
Switched to a new branch 'feature/stock-status'


app.get("/products", async (req, res) => {
  const { rows } = await db.query(
    `SELECT *, CASE WHEN stock = 0 THEN 'sold out' WHEN stock < 10 THEN 'low' ELSE 'in stock' END AS stock_status
     FROM products ORDER BY id`
  );

Commit and push the branch:

$ git commit -am "catalog-api: add stock_status to /products"
$ git push -u origin feature/stock-status


PS> git commit -am "catalog-api: add stock_status to /products"
PS> git push -u origin feature/stock-status

About a minute later each app has a second environment next to Production , named after the branch and deployed from it:

Notice that all three apps got a branch environment, even though only catalog-api/ changed. A new branch creates an environment for every app on the repository; after that, pushes only redeploy the apps whose folder changed.

Step 2: Test the changed service on its own URL

A branch environment's address is the branch name (with / turned into -), the app name and your workspace. Open the branch and production side by side in your browser:

https://feature-stock-status-catalog-api-yourworkspace.light-cloud.io/products
https://main-catalog-api-yourworkspace.light-cloud.io/products

The first product on the branch:

{"id":1,"name":"Espresso beans, 1 kg","price_cents":2400,"stock":39,"stock_status":"in stock"}

The same product in production:

{"id":1,"name":"Espresso beans, 1 kg","price_cents":2400,"stock":39}

The branch has the new field; production does not. Your stock numbers will differ.

Step 3: Know what a preview is connected to

A branch environment starts with the app's default variables, the ones you entered when you created the app. For Bean There that means:

The branch catalog-api uses the production database. Stock it reserves is real stock.
The branch orders-api calls the production catalog-api.
The branch web app calls the production APIs, so it does not show your change at all.

For a change to one API that you test with curl, that is fine. To click through the whole feature, point the preview services at each other.

Step 4: Wire a full preview

First, show the status in the shop. Still on the branch, the web app displays stock_status when the API sends it:

<span className={`stock ${product.stock_status === "low" ? "low" : ""}`}>
  {product.stock_status ? `${product.stock_status} (${product.stock})` : `${product.stock} in stock`}
</span>

Commit and push; only the branch web app redeploys. Then set these variables in each Stock Status environment (open the app, Stock Status , Settings , Environment Variables , Edit , then Save ):

App	Variable	Value
web	`VITE_CATALOG_API_URL`	`https://feature-stock-status-catalog-api-yourworkspace.light-cloud.io`
web	`VITE_ORDERS_API_URL`	`https://feature-stock-status-orders-api-yourworkspace.light-cloud.io`
catalog-api	`WEB_ORIGIN`	`https://feature-stock-status-web-yourworkspace.light-cloud.io`
orders-api	`WEB_ORIGIN`	`https://feature-stock-status-web-yourworkspace.light-cloud.io`
orders-api	`CATALOG_API_URL`	`https://feature-stock-status-catalog-api-yourworkspace.light-cloud.io`

These variables belong to the branch environment only; production is not touched. About a minute after the last save, open the preview shop at https://feature-stock-status-web-yourworkspace.light-cloud.io:

The preview shows the new status; the production shop still shows "39 in stock". Browse, but do not place orders here: the preview still shares the production database.

Step 5: Open a pull request

Open your repository on GitHub. It shows a banner for the branch you just pushed: click Compare & pull request , check that it goes from feature/stock-status into main, give it a title such as Show stock status in the shop, and click Create pull request.

Light Cloud comments on the pull request with a preview link for each app, and adds a check per app that turns green when its deployment is ready:

Reviewers can open the links without access to the Light Cloud console.

Step 6: Merge

Merge the branch into main and delete it, with Git:

$ git switch main
$ git pull
$ git merge feature/stock-status
$ git push
$ git push origin --delete feature/stock-status


PS> git switch main
PS> git pull
PS> git merge feature/stock-status
PS> git push
PS> git push origin --delete feature/stock-status

GitHub marks the pull request as merged as soon as its commits reach main. (The Merge pull request and Delete branch buttons on GitHub do the same.)

Two things happen:

Production redeploys only what changed. The merge touched catalog-api/ and web/, so those two redeploy; orders-api keeps running its current version.
The previews disappear. Deleting the branch removes the three Stock Status environments.

Step 7: Roll back a bad deploy

Previews catch a lot, but not everything. To practise, push a change straight to main that builds fine and is wrong: it divides every price by 100.

// Prices in whole currency units for the new price badge.
res.json(rows.map((row) => ({ ...row, price_cents: row.price_cents / 100 })));

A minute after the push, the shop sells espresso beans for $0.24:

Roll back:

Open catalog-api , Production , then the Deployments tab.
Click Rollback.

Pick the last good deployment. The one marked CURRENT is the bad one; choose the one below it, here the merge commit b49c2b4.

Read the confirmation and click Roll back.

The dialog says exactly what a rollback does: the environment serves the code from the earlier deployment, with no rebuild. Current environment variables stay as they are, and database changes made since are not undone. Because nothing is built, it is fast: in my test catalog-api served the correct prices again 13 seconds after I clicked Roll back , against about 70 seconds for a normal deploy.

Step 8: Fix main

The bad commit is still on main, and the next push would deploy it again. Revert it and push:

$ git revert --no-edit HEAD
[main 35f7829] Revert "catalog-api: prices in whole units"
 1 file changed, 1 insertion(+), 2 deletions(-)
$ git push


PS> git revert --no-edit HEAD
[main 35f7829] Revert "catalog-api: prices in whole units"
 1 file changed, 1 insertion(+), 2 deletions(-)
PS> git push

Your commit id will differ. The push deploys the reverted code, and main and production agree again.

Troubleshooting

The preview shop shows production data, not my change

The branch web app still uses the app's default VITE_* variables, which point at production. Set them on the branch environment (Step 4); saving rebuilds the preview with the new values.

The preview shop shows a CORS error

The branch APIs only allow the origins in their own WEB_ORIGIN. Add the preview web address to WEB_ORIGIN on the branch catalog-api and orders-api.

The VMware Lesson

Julia — Mon, 28 Sep 2026 07:44:26 +0000

In a New York court filing, AT&T, a company that negotiates for a living, stated that its VMware renewal under Broadcom's new licensing model amounted to a price increase of roughly 1,050%. Not fifty percent. Not double. Ten and a half times, for software already running, holding up systems that included services used by first responders, which is the detail that got the lawsuit its headlines.

The AT&T number is the famous one, and it isn't the ceiling: European cloud providers organized under CISPE reported member increases between 800% and 1,500%. This post is about why those numbers are the size they are, because the answer isn't greed as a personality trait. The answer is arithmetic performed on an install base that couldn't leave, and that arithmetic is the single most instructive case study available for anyone who signs infrastructure contracts. The lesson isn't "avoid Broadcom". It's that every locked-in vendor relationship you hold is an asset on someone's future balance sheet, priced at exactly your inability to exit.

The timeline of a repricing

The speed is the tell. Broadcom closed its roughly $69 billion VMware acquisition on November 22, 2023, and nineteen days later announced the end of perpetual licenses, the licensing model on which two decades of enterprise datacenters had been built. Products were fused into a handful of subscription bundles, so customers wanting one component now bought suites. The partner program was culled. Renewals began arriving at multiples of prior spend, and when customers balked, the follow-through included cease-and-desist letters to lapsed subscribers and litigation involving names as large as Siemens' US operations, while AT&T's suit alleged bad-faith pressure to convert to subscriptions it didn't want.

No exploratory phase, no gradual drift: a playbook executed in weeks, which tells you it was written before the ink dried. And by the only measure Broadcom answers to, it worked; the strategy has paid off financially, whatever the customer satisfaction surveys say. That's the part to absorb without flinching. This wasn't a miscalculation being punished by the market. It was a calculation being rewarded by it.

Why the numbers are that size

Here's the mechanism, and it's the same one this blog keeps circling from different directions. A hypervisor is close to the deepest possible position in the lock-in taxonomy: it sits under everything, touching every VM, every runbook, every disaster-recovery plan and every ops engineer's muscle memory, so leaving it isn't a migration, it's a re-platforming of the entire estate. Broadcom's pricing team didn't pick 1,000% out of spite. They estimated the cost of that re-platforming, in money, time, and risk, and priced renewals just under it, because any price below your cost of leaving is, in cold economic terms, a price you'll pay.

That's the general formula hiding inside the case study: your renewal price converges on your exit cost. Not on the product's value, not on what you paid last year, not on the relationship. On what leaving would cost you, as estimated by a party with every incentive to estimate it well. Most vendors don't run the formula to its limit because reputation, competition, and growth still discipline them. An acquirer buying a mature install base has exactly none of those constraints; the reputational damage lands on a brand it didn't build, the growth story is the extraction itself, and the customers, by construction, can't leave quickly. The contract terms AT&T thought protected it turned into two years of litigation instead of protection, which is what contracts are worth against a counterparty that has priced your litigation budget too.

The lesson, generalized

So run the VMware scenario against your own stack, because the scenario is portable. Every "strategic vendor" you depend on, virtualization, observability, identity, database, CI, is one acquisition announcement away from new ownership with a spreadsheet, and the consolidation era guarantees a steady supply of announcements. The questions that matter are the ones this case answers: What would a rational new owner charge us, given our real cost of leaving? How long would leaving actually take, tested, not asserted? Which dependencies sit so deep that their exit cost is effectively infinite, and did we price that when we adopted them?

Notice the VMware exodus that did happen: the customers who moved fastest weren't the angriest, they were the ones whose environments were already portable, boring, and mapped. Everyone else discovered that fury is not a migration plan. The time to compress your exit cost is while your vendor still has competitors and you still have alternatives, because the day the acquisition closes, your exit cost stops being an internal metric and becomes someone else's revenue target.

The steelman: Broadcom's defense has real parts

The uncomfortable defense deserves an honest hearing. VMware's perpetual-license pricing arguably underpriced two decades of critical software; subscriptions are the industry norm everywhere else; the product portfolio genuinely needed rationalization, and some percentage of the outrage is customers discovering the market value of something they'd been getting cheap. Markets also responded exactly as textbooks predict: virtualization alternatives, from Proxmox to the cloud providers themselves, have feasted on the discontent, and in five years the ecosystem may be healthier for the shock. Broadcom, on this reading, just marked an asset to market.

Mostly conceded, and it sharpens the lesson rather than blunting it. If the repricing was rational and legal, and it was, then it's repeatable, and "our vendor would never" is not a control. The only variable you govern in that equation is the exit cost, which means portability isn't a nice-to-have on some architectural wishlist; it's the one lever that caps what any future owner of any vendor can charge you. We build for that lever, and this case is why we get to skip the abstract argument for it. The concrete version fits in one question, and AT&T's lawyers can tell you the price of answering it late: if your deepest vendor were acquired this quarter, what number would appear on your next renewal, and what number would it cost you to say no?