DEV Community: flisk

Saylor Took the Classroom Offline for PHP2Shell

flisk — Wed, 21 Oct 2026 23:26:20 +0000

Saylor Academy did not discover a breach in a learner account. It found PHP under the classroom, and it pulled the plug.

On 21 October the team emailed learners from notices@saylor.org. A serious flaw in PHP, the software behind the sites, had been announced that day. To protect accounts, Saylor Learn (learn.saylor.org) and Saylor University (degrees.saylor.org) would go offline while the hosting partner installed the fix.

The window in that email is 6:00pm to 10:00am Eastern Daylight Time, with a return expected by 10:00am EDT on Thursday 22 October. A public Saylor page has also shown 8:00pm to 10:00am EDT. Confirm the live banner on learn.saylor.org before you treat either clock as final.

What learners actually lost

For those hours you cannot sign in, open a course, take a quiz or exam, or download a certificate. Progress, grades, and certificates stay put. Nothing completed is wiped. If you are mid-quiz, the email says submit it before the window starts. If the work runs long, the update goes on the maintenance page at learn.saylor.org.

That is the whole incident, and it is the point. The scary sentence in a security mail is usually "we were hacked." This one is "you cannot get in, because we would rather be down than exposed."

Why a school is in this series

PHP2Shell is the public name for CVE-2026-109618 and CVE-2026-109619. PHP rates each 9.2. Both can allow unauthenticated remote code execution on a PHP install that is serving web requests. Fixes landed on 21 October in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP's own line is that updating is the only complete fix.

Saylor is not a hyperscaler. It is a free course platform with quizzes, exams, and certificates. That is exactly the data you do not leave on an unpatched runtime while a proof of concept is already circulating. The host installs the package. Saylor owns the outage message. Learners own the inconvenience.

The local version of the same mail

If your app is PHP and the image tag is older than those four releases, you are in the same bucket as learn.saylor.org. A laptop container is not exempt once it is reachable. Bump the tag, restart the workers, and do not call it patched until the new binary is the one answering requests.

Old workers keep the old code. That is the step people skip, and it is why a maintenance page exists at all.

Sources: Saylor learner notice, 21 October 2026; PHP security advisory.

DigiD Went Dark on Purpose. Logius took DigiD, MijnOverheid, and Overheid.nl offline on 21 October. It was a precaution, not a confirmed intrusion.

flisk — Wed, 21 Oct 2026 23:26:00 +0000

The Dutch government did not wait to see if PHP2Shell was theoretical. It turned off the sites people use to prove who they are.

On Wednesday 21 October, Rijksoverheid said a number of government sites were taken offline as a precaution after two critical flaws in PHP. The list it named included Overheid.nl, MijnOverheid.nl, and DigiD. The NCSC had not, at that point, seen signs the flaws were being exploited. The sites still went down. Logius, which runs MijnOverheid, confirmed the shutdown. NRC also reported the Tweede Kamer site offline the same day.

Read that again. The identity portal went dark before the patch, not after a breach notice.

What stayed up, and what did not

Reporting through the day was messy, which is normal when the website and the login protocol are different things. The DigiD website was unreachable. Some reports said you could still sign in with DigiD on other sites that were still online. The app was partly down. By Wednesday evening, MijnOverheid and then DigiD.nl were reported back. Overheid.nl was still cited as down in at least one late update.

Do not publish this piece with "DigiD is down" in the present tense. Stamp it. As of Wednesday evening, 21 October, the precautionary outage had started in the morning and the identity sites were coming back after PHP's fixes landed around 16:00 Dutch time.

The sentence the NCSC used

This was not sold as an attack. A Rijksoverheid update said the patches were available and that site owners should apply them as fast as possible. The earlier advice was to weigh the risk and, if needed, take the site offline until the update existed. PHP had told users to prepare for a release at 14:00 UTC. Dutch time, that was 16:00.

That is the operational lesson. A CVSS 9.2 in the language under the site is not a ticket you schedule for Friday if the site is DigiD. You eat the outage, you install 8.5.12, 8.4.27, 8.3.36, or 8.2.35, you restart the workers, and you bring the hostname back only after the new binary is the one serving.

Hospitals, municipalities, RTL, and council-information platforms were in the same Dutch wave. They get their own mentions later if this series keeps going. This post is about the org that had to explain to the whole country why the login page was a maintenance screen.

Sources: Rijksoverheid, 21 October 2026; NRC; PHP advisory.

Cygames Scheduled the Outage for the Patch, Then Moved It Earlier

flisk — Wed, 21 Oct 2026 23:25:28 +0000

Cygames did not bury the cause in "emergency maintenance." The posts named PHP.

On 21 October the company said Umamusume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and other live titles would go down so the servers could be made safe. The Umamusume account told players they would not be able to start or play during the work. Famitsu reported the original window as about 23:00 Japan time on the 21st, lined up with the PHP fix publication expected that hour. Granblue was planned through 07:00 on 22 October, with a warning the end time could move. Umamusume and Shadowverse did not publish an end time.

Then the start moved. A later Umamusume notice pulled maintenance forward to about 22:00, and said it might move again. That is what a broken embargo looks like from the operator side. You planned the outage for the patch. The patch, and the exploit talk, showed up early. You start early.

One company, three clocks

This is a useful contrast with Saylor, which had one host and one overnight window, and with FFXIV, which froze new logins and left existing sessions alone. Cygames had several games on the same language bug and did not pretend they would return together. Granblue got a planned end. The others got "we will tell you." That is better than a fake 7:00am that slips for six hours while players refresh a status page.

The fix they were waiting on is the same four releases as everyone else: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, from the 21 October security release. A game server that still answers on an older worker after that release is not "in maintenance." It is late.

If you operate more than one PHP front, write the notice per product. Shared cause, separate end times, and a sentence that the start can move if the patch moves. Players can forgive a dark game. They do not forgive a countdown you already knew was fiction.

Sources: Famitsu, 21 October 2026; PHP advisory.

Final Fantasy XIV Closed the Door, Not the World

flisk — Wed, 21 Oct 2026 23:25:05 +0000

Square Enix did not have to take Eorzea offline to take PHP offline. It stopped new logins.

On 21 October the Lodestone notice for Final Fantasy XIV said new logins were temporarily suspended across all worlds to address a critical vulnerability in PHP, the language hitting systems worldwide. Secondary reports the same day said people already logged in could keep playing, and that there was no public return time on the notice.

That split is the story. A game login service is a web front on a live world. You can refuse the next authentication without dumping every character who is already past the gate. It is still an outage. Anyone who disconnected, anyone on a new session, anyone who needed the web layer, was stuck. It is a narrower outage than "the game is gone," and it is a more honest one than leaving the login form up on a runtime PHP had just called unsafe.

What this is not

This post is not a claim that Square Enix was breached through PHP2Shell. The notice that was public on 21 October is a maintenance action tied to the PHP flaw. Account-security warnings from earlier in the month are a different incident. Do not merge them in the headline.

PHP's fixes that day were 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Until those, or a vendor build that contains the same fix, are the binaries behind the login service, a suspended login is the correct product decision. Opening the form early because players are angry is how a maintenance window becomes an incident report.

If you ship a game, a store, or a course site with a PHP login in front of a system that can survive without new sessions, copy this shape. Freeze new auth. Say why in one sentence. Do not invent an end time you do not have. Bring the form back only after the worker restart, not after the package download.

Sources: FINAL FANTASY XIV Lodestone notice, 21 October 2026; PHP advisory.

Wikipedia Stayed Up. Toolforge Did Not.

flisk — Wed, 21 Oct 2026 23:24:42 +0000

The Wikimedia Foundation did not switch Wikipedia off and go home. It switched off the parts where it could not promise the PHP version.

On 21 October the foundation said it was dealing with two critical PHP flaws that hit any site running PHP, not just Wikimedia. Readers might see wiki outages during the work. Supporting services were taken offline on purpose until they could be patched. The names that matter are Toolforge and Cloud VPS. Those host a lot of PHP apps. Volunteer developers run them. Some of those users pick their own PHP version. Staff cannot safely flip that back on by pushing one package.

A later community status page told the same story in a list. Cloud VPS and Toolforge, including *.wmcloud.org, *.wmflabs.org, and *.toolforge.org, were offline and might stay that way longer. Wikibase Cloud was down. Phabricator, translatewiki.net, GitLab, and doc.wikimedia.org were later marked restored. Zuul's status page stayed down for the same reason.

The outage is an ownership problem

This is the post in the series that is not about a vendor installing a patch overnight. Saylor could hand the window to a host. Logius could take DigiD down and bring it back. Wikimedia can patch what it operates. It cannot patch a Toolforge tool whose owner chose the runtime.

That is why the foundation's note says some of those services may be offline longer, and why staff were triaging, emailing documented owners, and upgrading only where they had access. A security bug in core PHP becomes an inventory bug the moment more than one team can pin a version.

If you run a platform where users bring their own PHP, you are in this post, not the Saylor post. Taking the platform offline is the honest move until every reachable worker is on 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or on a vendor backport you have actually installed. "We patched the main wiki" is not a status for the side hostnames.

Sources: Wikimedia Diff, 21 October 2026; Wikitech community status; PHP advisory.

Pokémon Home Went Down With the PHP Patch

flisk — Wed, 21 Oct 2026 23:24:27 +0000

Pokémon did not get a neat single-paragraph post in the first wave of PHP2Shell coverage. It got a list, and the list is still worth a post if you label it as a list.

On 21 October, GoNintendo and Dexerto reported that Pokémon Home, Pokémon Champions, and Pokémon Sleep were offline, and that the official Pokémon Japan site was down with them. The cause they gave was the same pair of critical PHP flaws that had already pulled Umamusume, Final Fantasy XIV logins, and a pile of government sites. I have not opened a first-party Pokémon notice for this draft. If you have the official post, swap this paragraph for a quote and a link before you publish. If you cannot find one, say "reported" in the first sentence and do not upgrade it to "Pokémon confirmed."

Why it still belongs in the six

Home is not a marketing site. It is the box where creatures, and the account around them, live. Sleep and Champions are live services with logins. Taking those down on patch day is the same decision Saylor made for certificates and Logius made for DigiD: the data is worth more than the uptime, and the bug is in the language, not in one route you can feature-flag off.

PHP's position on 21 October was blunt. Every PHP install serving web requests was in scope. The highest risk they called out was mod_php, where an unauthenticated request can hit the bug before application code runs. A game studio cannot audit its way out of that in an afternoon. It can pull the service, install 8.5.12, 8.4.27, 8.3.36, or 8.2.35, restart the workers, and reopen.

How to end the series

Six orgs, one pattern. Saylor told learners the grades were safe and the login was not. Logius told a country the identity site was a precaution. Wikimedia could patch its own stack and still had to darken Toolforge. Square Enix froze new sessions. Cygames moved the start time when the patch moved. Pokémon's live services showed up on the same day, in the same bucket.

None of these posts are a breach report. Do not write them as one. The publishable fact is the outage, the clock, and the version that has to be running before the hostname comes back.

Sources: GoNintendo, 21 October 2026; Dexerto; PHP advisory.

Three Sentences in This Repo Cannot All Be True

flisk — Wed, 21 Oct 2026 23:03:15 +0000

A small project can survive a missing feature. It has a harder time surviving two docs that describe different products. Flisk currently has that problem in public. If you are about to write a tutorial from one page, read this first, then generate the files and believe those.

The binary is the smallest version of the bug. The README says npm install -g @flisk-sh/flisk installs the tdk command. The Helm page and the comparison page use tdk. The feature guide uses flisk. Run tdk --version and flisk --version. Quote the one that exists on your machine. Do not quote both as if they were a style choice.

The database is not allowed to have two default names

The feature guide says the project database is app_dev by default, and that backends use DATABASE_URL. The scope note, read from a scaffolded backend's generated Compose file and .env in Flisk 1.3.86, says one shared Postgres 16 container and one database per stack, named <project>_<stack>, with the password in .env.

Those sentences cannot both be the default. One of them is stale, or they describe different layers and nobody wrote the layer down. Before you put either name in application code, print the URL the container actually received. Then keep that name out of source anyway. The earlier piece in this series is the rule: a local database name is a harness fact, not a constant.

The comparison page also says Flisk provisions NATS. The feature guide's always-on list is proxy and database-management. NATS is real enough to have had a bug: a changelog entry says the focus filter left nats disabled, so a service with the NATS feature retried its broker until someone ran tilt enable nats by hand. "Automatically provisioned" and "disabled until you enable it" are different products. If your service needs a broker, check tilt after up. Do not assume the intro paragraph started it.

Prisma is not a default that is also opt-in

The feature guide shows a backend example with "features": ["prisma"] in the same breath as the default feature list. Later it says Prisma is not enabled by default. Add "prisma" only together with prisma/schema.prisma and the prisma and @prisma/client dependencies. The generated Dockerfile copies prisma/ and runs prisma generate. Without those files, the image fails to build.

That second paragraph is the one to follow. The example is how a tutorial creates a red build and calls the tool broken. Enabling a feature flag is not the same as owning the schema the flag expects.

The same page puts golden_image inside an "optional, disabled by default" snippet and then says golden-image is on by default. The troubleshoot page is clearer about the consequence either way: <project>-l1:latest and the other golden tags are local images. They are not in a registry. A CI job that has not built them cannot build .autogenerated/Dockerfile.app.autogenerated. Turn the feature off only if you know which Dockerfile you are about to own.

Doctor used to lie about a free port

One contradiction already got fixed, which is why the class of bug is worth knowing. tdk doctor checks that host ports 80, 443, and 5432 are free and names what holds them, often a local Postgres. A changelog entry says the check used to bind 0.0.0.0 and 127.0.0.1 at the same time. On Linux the second bind collided with the first, so a free port was reported taken. It now probes them one after the other.

If an old doctor told you port 80 was busy and nothing was listening, that report can be the bug, not the machine. Re-run doctor after updating. On Linux and WSL2 a non-root user still cannot bind port 80, so up may move Traefik to the fallback range and print a URL with a port. That part is not a lie. The printed URL is the URL.

tdk doctor also cannot see a chart. The Helm page says it checks local readiness and service issues, not production configuration. A Docker Desktop window can be open while the engine is not responding. Doctor's own hint, from the L1 troubleshoot page, is to quit Docker Desktop completely, reopen it, and wait until it is running. A whale icon is not a daemon.

What to quote, until the pages agree

If you are about to write	Quote this	Do not quote this
The database name	The `DATABASE_URL` in the generated env for that stack	`app_dev` or `<project>_<stack>` from memory
Whether NATS is up	`tilt` after `up`, for that feature	The comparison intro alone
Whether Prisma is on	The `features` array, plus a schema and the two packages	A sample manifest labeled "default"
Which command to document	The binary `--version` printed	Whichever page you had open
Whether the chart is valid	`helm lint` and `helm template` on the pinned chart	`tdk doctor` or `tdk config verify`
Whether port 80 is free	A current doctor, then the URL `up` printed	A remembered "port taken" from an old binary

Optional infra has a quieter trap of the same family. Monitoring, ELK, and Debezium are free and off by default. The feature guide marks monitoring and ELK as high resource. Enabling them because the page listed them is how a 16 GB laptop stops being a daily driver. Golden layers are the optional-looking feature that is already on. ELK is the default-looking cost that is not.

The size of a contradiction

None of these are the product. The product is still a manifest, a local stack, and a chart you write yourself. The docs are part of the surface area, though, and an agent will treat the first page it opens as the spec.

When two pages disagree, generate the file or run the command. Then fix the page that lost. A tutorial that picks a side without that check is how the third sentence appears.

Do Not Boot a Cluster to Change a Button

flisk — Wed, 21 Oct 2026 23:02:59 +0000

A local cluster feels like rigor. Often it is a tax.

kind and minikube give you a Kubernetes API on the laptop. They do not give you an inner loop. Helm, kubectl, Skaffold, or Tilt still has to sit on top. Flisk's comparison doc draws the line in the place most tool pages smudge it: if your software talks to that API, you need the cluster. If your software is a service, a page, a worker, or an agent, the cluster is an operational target, not a dependency of the edit you are making.

When the cluster is mandatory

Refuse Flisk, and refuse "just use Compose," when the thing you are building is the cluster:

an operator, a CRD, or a reconciler
an admission webhook
ServiceAccount RBAC you must see fail
a Pod disruption budget, a NetworkPolicy, a CNI plugin
a service mesh
a Helm chart or Kustomize overlay whose job is to install cleanly

Those are not local-dev preferences. A Docker network will not grow a kube-apiserver because you wanted parity. Skaffold is the better inner loop when the same pipeline should dev against a cluster and run in CI. DevSpace is the better inner loop when the code should execute inside a remote pod or a vcluster, especially if you need the file sync to run both ways.

Native Windows without WSL2 is a harder stop than a philosophy. The comparison doc says flisk up exits 1 on native Windows. Inspection still works: flisk --version, flisk doctor, flisk up --dry-run. Startup needs Ubuntu on WSL2. Compose does not have that cliff. If the team will not install WSL2, the evaluation is over.

When the cluster is a costume

The comparison doc's overhead claim should be quoted as a claim, not as a bench this repository measured. It says a local Kubernetes control plane typically consumes 4 GiB to 8 GiB before your application starts. Use that as a reason to measure your own minikube start, not as a number to put in a slide without the word "typically."

The costs that do not need a RAM chart:

You maintain Deployments, Services, and Ingress objects so a developer can hit a route.
On kind, a locally built image has to be loaded into the node. That load is part of the loop, not a footnote.
Ingress wants a controller, and sometimes MetalLB or minikube tunnel, before *.localhost has an equivalent.
A remote dev cluster adds network delay, someone else's namespace policy, and a cloud bill to an edit that did not need any of them.

Flisk's counter-offer is plain Docker, Tilt live update into the running container, Traefik on *.localhost, and flisk up <stack> instead of a namespace selector. Production stays on Helm, Kustomize, or Argo CD. The chart remains the thing you lint before merge. It stops being the thing you boot to change a button.

Plain Tilt is the other honest alternative. If the team already writes Starlark, deploys with k8s_yaml(), or runs host processes beside containers, Flisk is an abstraction over a file they meant to own. flisk eject points at the generated file if you want that ownership later:

tilt up -f .tdk/.tdk-out/Tiltfile -- --focus=<stack>

The migration that does not throw the chart away

From kind or Skaffold to Flisk, keep the production manifests. Add service.json for the inner loop. Stop requiring every laptop to run kind create cluster before a UI change. Charts still install in CI. That is the correct place to discover that a template is wrong.

From Flisk back to a cluster, the work is the work you skipped: start the cluster, install the ingress or the operators, write the chart, deploy, forward a port. There is no command that turns a stack into a kind cluster. If that missing command is what you wanted, you wanted Skaffold.

Bring-your-own is the middle. A service that already has an image stays on that image. Flisk routes and health-checks it. The image your pipeline ships can be the image the laptop runs, which is the one parity that is worth paying for. Cluster API parity is a different bill.

A one-question filter

Ask what the next edit needs to be true.

If the edit needs a ServiceAccount, a CRD, or a NetworkPolicy to fail realistically, start the cluster and do not apologize. If the edit needs a handler, a query, a prompt, or a pixel, a control plane is time you will not get back. Boot the containers. Leave the API server for the pull request that is about the API server.

service.json Is Not values.yaml

flisk — Wed, 21 Oct 2026 23:02:32 +0000

The sentence that keeps getting shortened is this one: Flisk and Helm are not alternatives.

tdk up starts Docker containers on your machine through Tilt. helm upgrade creates Deployments and Services in a cluster. service.json describes the local service. values.yaml configures Kubernetes objects. The files share a few words. They are not a translation.

The project's Helm note says there is no export command. tdk config verify checks generated project files against .tdk/project.json. It does not lint service.json, and it does not lint Helm values. tdk doctor checks whether this machine can run the local stack. A green doctor is not a green chart.

The words that look like a mapping

This table is the conceptual one from the Helm doc. Read the last column louder than the first.

You wrote this locally	Someone will look for this in the chart	Why the copy fails
`appName`	Release name or controller id	Identity only. Chart naming is configurable.
`appType`	Deployment, Job, or CronJob	A local type does not select the cluster controller.
`port`	`service.main.ports.http.port`	Confirm the container port and the Service port for the image you actually published.
`healthCheckPath`	Readiness or liveness path	Add the probes. Tune them. A local curl check is not a probe spec.
`dependsOn`	Hooks, init containers, ordering	Local startup order is not a cluster startup contract.
Traefik on `*.localhost`	Ingress or Gateway host	Class, DNS, and TLS are yours.
Local Postgres	External database or a chart dependency	Lifecycle, persistence, credentials, backups.

A worker is the cleanest example. Locally it is a process in a container. In the cluster it is a Job or a CronJob, and a CronJob needs a schedule. Flisk cannot infer either. A frontend that nginx and Traefik served on your laptop still needs an Ingress or a Gateway that you configure. The local route disappearing from the laptop does not create that object.

Do not copy the generated tree

.autogenerated/ is local Docker and Tilt output. .tdk/.tdk-out/ is the same family of output. Neither is a chart. The failure mode is a pull request that adds the generated Dockerfile, the generated nginx config, or the generated Tiltfile under charts/ because an agent noticed the files existed and assumed they were the deployable form.

They are not. The local image is built from golden layers that exist only on the machine that built them. Flisk does not publish that image. Before Helm can run anything, your existing CI has to build and push an image to a registry the cluster can pull. The tag in values.yaml is that image. It is not shop_orders-api:dev.

The handwritten example in the repo keeps bjw-s-labs app-template for production and pins oci://ghcr.io/bjw-s-labs/helm/app-template at 5.2.1. It shows an image repository, a tag, and an HTTP port. It intentionally leaves replicas, probes, ingress, PVCs, resources, security context, identity, and autoscaling to the person who owns the release. The example is a handoff sketch, not a supported production chart. The doc tells you to pull that pinned chart and lint the sample without installing it:

helm pull oci://ghcr.io/bjw-s-labs/helm/app-template \
  --version 5.2.1 --untar --untardir /tmp/tdk-helm-example
helm lint /tmp/tdk-helm-example/app-template \
  --values examples/one-backend-helm/values.yaml
helm template api /tmp/tdk-helm-example/app-template \
  --values examples/one-backend-helm/values.yaml

That is the whole integration. Keep the chart you already use. Flisk does not install it and does not take it over.

The review that actually catches the drift

tdk up shop can be healthy while the chart is a lie, because nothing in the local loop reads the chart. Put the check in the pull request instead.

The image repository and tag in values point at an image CI published. Not at a local golden-layer tag.
The container port in values was confirmed against the image, not copied from service.json because the numbers matched last month.
Probes were added on purpose. healthCheckPath was an input to that decision, not the probe.
A worker has an explicit Job or CronJob, and a CronJob has a schedule.
A frontend has an Ingress or Gateway that is not *.localhost.
No file under .autogenerated/ or .tdk/.tdk-out/ was copied into the chart.
Secrets, IRSA, HPA, node selectors, and PVCs are still owned by the deployment, because the local manifest has nowhere to put them.

Skip Flisk entirely when helm install, Compose, or a Tiltfile you already like is the local environment. Adding service.json beside a working chart does not make the chart more true. It adds a second file that can drift.

The size of the handoff

Flisk's job ends at the laptop. Helm's job starts at the registry. The dangerous area is the inch between them, where a port, a path, and an image name look portable.

Carry those three across by hand. Then lint the chart. The CLI that started the container is not going to do it for you.

local-jwt Is Not an Identity Provider

flisk — Wed, 21 Oct 2026 23:00:42 +0000

Flisk is kind to a new service. That kindness is the bug.

A scaffolded backend, read from the files flisk project and flisk resource generated in Flisk 1.3.86, boots with a working login, a working database, a working URL, and a migration that already ran. A real application and a staging environment were not part of that reading. If your code treats those conveniences as the world, it will pass every local test and fail the first time it meets an identity provider.

The scope note says this plainly. Local is the intended use. CI can be a throwaway copy of local. Staging and production are out of scope. There is no command that deploys, exports a chart, or writes cluster config.

The harness, line by line

These are not opinions. They were read from the generated Compose file and .env of that scaffolded backend. Check them against your own tree before you quote them in a design doc.

What your app sees	What Flisk actually gave it	What production will not give it
`NODE_ENV=development`	Set in the container. `TDK_ENV` comes from `TILT_ENV`, default `development`	Your flags, including a real `production`
A JWT that verifies	`AUTH_MODE=local-jwt`, signed with a `JWT_SECRET` generated per project in `.env`	Your identity provider and key management
Postgres on a name you can guess	One shared Postgres 16 container. One database per stack, named `<project>_<stack>`. Password from `.env`. Data in a Docker volume	A managed database, backups, and a migrator that runs once
Tables already exist	Services may migrate at container start. `AUTO_MIGRATE` is the escape hatch. `flisk doctor` warns about it	A one-shot job, not "every replica migrates on boot"
`http://api.shop.localhost/...`	Traefik on `*.localhost`, host ports 80 and 443 when free, otherwise a port from 8080–8180 and 8443–8543	Your ingress, DNS, and certificates
Secrets that are just there	Git-ignored `.env`, or Infisical if `TDK_SECRET_PROVIDER=infisical`	Your secret store
It fits	Scaffolded backend limits: 512 MB and 0.5 CPU, with 256 MB and 0.2 CPU reserved	Replicas, real limits, autoscaling
Unhealthy means curl failed	Generated services get a Compose health check that runs `curl` inside the image. A bring-your-own service gets no Compose health check. Traefik's own check still applies. That was read in `compose.star`, not executed	Your readiness and liveness probes

HTTPS is the line to be careful with. Traefik has an HTTPS entry point. How certificates are handled was not checked. Do not write "Flisk does local TLS" in a security review.

Three strings that must never land in source

The failure is not that Flisk uses them. The failure is an agent, or a tired human, pasting them into the application because the request succeeded.

*.localhost is a route, not a domain your frontend may hardcode. tdk up prints the URL. On Linux and WSL2 a non-root user cannot check port 80, so the fallback range is used and the printed URL includes a port. An agent that writes http://api.shop.localhost/api/orders into a client has coupled the product to one machine's port luck. A resource named orders-api is served at /api/orders because a trailing -api is dropped. That rule is also a Flisk rule. Read the base URL from the environment.

<project>_<stack> is a local database name. The next stack on that same Postgres container gets its own database, which feels like isolation and is not a production topology. One volume holds the data. flisk down keeps the project networks unless you pass --prune-networks. So "I reset the stack" often means "I stopped containers and left the network sitting there." If your seed assumes a fresh network or a fresh volume, it will pass on a new laptop and fail on the laptop that has been up since Tuesday.

local-jwt plus a project-local JWT_SECRET is a dev login. It is not a tenant model, not a rotation story, and not something another service should accept outside this Compose file. The alternative Flisk offers is an identity service when you add one. Add one before you demo auth to anyone who will ask where the keys live.

AUTO_MIGRATE on boot is the same shape of bug. It makes the first hour painless and makes "two replicas started together" a coin flip. Doctor warns. The warning is not a migration runner.

CI is allowed to be this fake. Staging is not.

The repository's own quickstart workflow runs a real flisk up on a GitHub-hosted runner. That is a throwaway environment, which is a fair use. A copy-paste workflow for your own repository lives in the CI docs, and its flisk up job had not been run on GitHub when the scope page was written. Do not treat an unread recipe as evidence that your pipeline already does this.

A green CI job against NODE_ENV=development and local JWT does not answer the production question. The scope note's own remedy is small:

Run the image your CI built, through a bring-your-own resource, at least once.
Read hosts, database names, and auth settings from the environment. Do not branch on "we are on *.localhost."
Test any NODE_ENV-dependent behavior in a run that is not Flisk.

Bring-your-own narrows the gap. It does not make the laptop a cluster. Flisk still will not generate the Helm values. The port, the image, and the health path will exist in service.json and again in the chart. Nothing syncs them. Changing one is a review of the other, every time.

A review checklist that fits in a pull request

Reject the diff if application code contains any of these:

localhost as a service address, including api.<stack>.localhost
the stack database name, or a password read from a comment instead of the environment
AUTH_MODE, JWT_SECRET, or a token signed for local JWT
a migration invoked because the process started, with no separate migrator
a health check that assumes curl exists in an image you did not build
a copy of .autogenerated/ or .tdk/.tdk-out/ pasted into a chart

Then ask one question the laptop cannot answer: what happens when this process starts twice, against a database it is not allowed to create, on a host it has never heard of?

If the answer is "Flisk handles that," the feature is still a local convenience. Ship the other behavior.

The size of the kindness

Flisk should keep being kind. A new service should get a URL, a database, and a token that verifies. The application does not get to remember how that kindness was implemented.

Local is a harness. The moment the harness is in source, you no longer have a service. You have a demo that only boots in the room where it was written.

There Are Two Dockerfiles. Your Agent Should Touch Neither.

flisk — Wed, 21 Oct 2026 22:58:18 +0000

A coding agent will edit a Dockerfile the way a helpful intern edits a wiki: confidently, locally, and with no memory of the last time someone did the same thing three services over.

That is fine in a three-service repo. It is a slow accident in a landscape. Flisk makes the accident specific, because it already has two Dockerfiles, and flisk up builds only one of them.

If your agent cannot tell those two files apart, it should not be allowed to touch either.

The file that runs is not the file that looks like source

Read this from the project's own scope note, not from a launch tweet. For a generated service, flisk up builds services/<stack>/<name>/.autogenerated/Dockerfile.app.autogenerated. The build context is the project root. The stages start from local golden images, named like <project>-l1:latest, -l2, -l3-backend, -l4-backend. Those images are built on your machine. They are not published.

So that Dockerfile cannot be built on a laptop, or in a CI job, that has not built the golden layers first. The final stage runs as user bun. The local tag looks like shop_orders-api:dev. The production and development targets in that file are the same stage. It is a local image.

flisk resource also writes a plain Dockerfile next to service.json. It even has a comment saying so. flisk up does not build it. Its PORT, EXPOSE, and health check follow the port in service.json. It used to say 3000 while a backend ran on 4000, which is exactly the class of lie an agent will reintroduce if you let it "clean up" the file. The plain Dockerfile is a starting point for building outside Flisk. Whether it is fit to ship was not checked. Do not promote it to a production image because it sits in the nice part of the tree.

File	Who may edit it	What actually runs it
`service.json`	You, or the agent, if the task is a topology change	Nothing. It is the input.
`.autogenerated/Dockerfile.app.autogenerated`	Nobody by hand	`flisk up`, after local golden layers exist
Plain `Dockerfile` beside `service.json`	Nobody, unless you are leaving Flisk's local loop	Not `flisk up`. A later, separate build, if you choose one
Your own Dockerfile on a bring-your-own service	You	Your image, if you pointed the resource at it

Bring-your-own is the escape hatch, not a magic sync. If you want the image you ship to be the image that runs locally, use a bring-your-own resource with your own Dockerfile or --image. That shrinks the gap. It does not make local and production the same computer.

What the agent is good at, and what it will counterfeit

The agent is good at the thing inside the container: a handler, a query, a failing test, a prompt, a tool call.

It is bad at the thing around the container, because that thing has to be the same on every service:

the port in the manifest, the route, and the health check
the host npmrc versus the container npmrc
the Vite config the dev server uses versus the one nginx serves
the golden layer the local Dockerfile expects
the Helm value that production actually reads

Flisk does not generate a chart. .tdk/.tdk-out/ and .autogenerated/ are local output. Copying them into Helm is how "works on my laptop" becomes a deploy. The port, the image, and the health path will exist twice, once in service.json and once in the chart. Nothing keeps them in sync. An agent that "helps" by updating only the file it can see will desync them in one commit.

A generated frontend makes the surface obvious. Under .autogenerated/ you get the local Dockerfile, an nginx config, host and container TypeScript configs, host and container package configs, Vite configs, an API client, and a short AGENTS.md. A Bun backend swaps in backend env, Vite, and Prisma files. Python, Go, and Rust still get a local Dockerfile, and skip the Bun-only pile. The exact set depends on appType, language, and features. The rule does not.

Edit service.json. Let the generator write the rest.

The warning file is a sign, not a policy

Each service's .autogenerated/AGENTS.md tells a coding agent that the directory is generated. On the free in-repo generator, that file is a short notice. It is not a substitute for a root policy. The downloaded agents-md implementation is the one their feature table marks as Premium. Do not assume a two-paragraph warning will stop a determined agent that was told to "make the container build."

Put the real rule where every task starts:

# AGENTS.md

## Source of truth
- Topology changes go in `service.json` or `.tdk/project.json`.
- Application code stays in the service, outside `.autogenerated/`.
- Production deploy config is Helm or the pipeline. Flisk does not generate it.

## Do not edit
- `.autogenerated/**`
- `.tdk/.tdk-out/**`
- `.autogenerated/.tdk-contract/**`
- The plain `Dockerfile` next to `service.json`, unless the task is explicitly "prepare a non-Flisk build" and a human asked for that file.

## Commands
- Inspect: `flisk doctor`
- Preview: `flisk up <stack> --dry-run`
- Run: `flisk up <stack>`
- Check the generated contract: `flisk config verify`
- After a manifest change, run `flisk up` again. Do not patch generated output to match the manifest.

## Stop and ask
- The task needs a production image, a cluster, or a secret from `.env`.
- A generated file looks wrong. Change the manifest or the generator, then regenerate.
- Local auth, `*.localhost`, or the shared Postgres database name would have to be hardcoded. Read those from the environment.

Use tdk in that file if that is the binary your install prints. The package and the docs still disagree on the name. The boundary does not.

This file is guidance, not a sandbox. An agent can ignore it. The drift check is the part that does not care about the agent's manners.

The gate is more useful than the lecture

flisk up compares generated service files with the snapshot in .autogenerated/.tdk-contract/ before Tilt starts. A hand edit blocks startup and names the file. --dry-run runs the same check and starts nothing. service.yaml is exempt from that comparison. It is a projection of service.json for Tilt. Edit the JSON.

flisk config verify checks the wider contract under .tdk/.tdk-out/, validates discovered manifests, and compares service files with their snapshots. flisk doctor is for machine readiness, not for "did an agent rewrite nginx."

The repair is boring, which is the point. Move the intended change into service.json, then run flisk up so the outputs are regenerated. flisk config regenerate replaces generated project files. A hand-edited service file keeps blocking until the edit is gone or the check is explicitly bypassed. Bypass is a human decision. It is not a step in an agent prompt.

The earlier post on derived artifacts covers that gate. This post is about the file the agent can see and still misunderstand.

When the agent should edit a Dockerfile

Sometimes the Dockerfile is the source. Say so, or the rule becomes superstition.

Two or three services and a Compose file that already fits on one screen. Flisk is extra machinery. Let the agent edit Compose and the Dockerfile, then read the diff yourself.
A bring-your-own service whose image is built by your CI. The Dockerfile next to that service is product infrastructure. Review it like code. Do not also let the agent "fix" the generated local Dockerfile so they match. They are not supposed to match line for line.
A one-off debug of the golden-layer build, done by a human who is changing the generator. That edit belongs in the generator, then every service regenerates. It does not belong in one service's .autogenerated/ folder as a snowflake.

The test is ownership. If deleting the file and running flisk up would recreate it, the agent does not own it. If deleting it would break the image your pipeline ships, the agent may edit it, and a human reviews the diff before merge.

One loop that keeps the agent in its lane

flisk doctor
flisk up shop --dry-run
# agent edits application code, or service.json if the task is topology
flisk config verify
flisk up shop

If verify fails because the agent touched .autogenerated/, revert that path. Do not ask the agent to reconcile the generated Dockerfile with the plain Dockerfile. That reconciliation is the bug.

Local Flisk also leaks fake production if you let application code depend on it. A scaffolded backend runs with NODE_ENV=development, local JWT auth, one shared Postgres 16, and *.localhost routes. Those are environment facts. The moment they are string literals in source, the agent has coupled the product to a dev harness. The scope note's rule is the right one: run the real production image through a bring-your-own resource at least once, and keep Flisk-only hosts and database names out of the code.

The size of this rule

Flisk is still a small CLI. This rule is the large part. A coding agent can write the service. It cannot be the system of record for how that service is built, routed, and health-checked on a laptop, and it definitely cannot be the system of record for the image you ship.

Give it service.json, the application tree, and a root AGENTS.md that names the forbidden directories. Take the Dockerfiles away.

Your Stack Has a Size. Flisk Only Fits One of Them.

flisk — Wed, 21 Oct 2026 22:47:28 +0000

"We have microservices" is not a sizing input. Twelve services in one Compose file is a different job from twelve services that each own a manifest, a route, and a health check. Flisk is opinionated about which of those jobs it wants.

This is the decision table I wish every "should we adopt this" thread started with.

Three sizes, three tools

Your actual stack	Better default	Why
2–5 services, already containerized	Docker Compose	One file, no new abstraction, everyone already knows it
You already love your Tiltfile	Plain Tilt	Flisk's job is to write that file. If it exists and works, leave it
Local must match the cluster	kind, minikube, Skaffold, DevSpace, Garden	Those tools target Kubernetes. Flisk does not
10–50+ services, painful Compose, agents rewriting Dockerfiles	Flisk	One `service.json` per service, `flisk up <stack>`, generated Tilt loop, no local cluster
You need a platform, SSO, and an SLA tomorrow	Not this, yet	Four listed adopters, small community, optional Premium at $19/dev/month. Enterprise is "contact them"

The middle row is the product. Everything else is a way to waste a week proving a README you could have believed.

What "medium" feels like on a Tuesday

You are not booting an ERP. You are trying to change checkout without starting payroll.

Flisk's answer is stack-scoped startup. flisk up shop starts that stack. flisk up shop --dry-run prints the services and URLs and starts nothing. Ports come from the manifest. Routes land on a local domain such as http://api.shop.localhost/... when port 80 is free, otherwise on a port the CLI prints. Dev ports bind to 127.0.0.1 unless you set TDK_BIND_ADDRESS.

That is the feature. Not "100 services on a laptop."

The 100-service figure is a generated /health fixture: small stub services, all routed through Traefik, used as a boot test. The project says a 14-service stack is the daily driver on a 16 GB M1, and a 27-service monorepo runs on the same engine. Quote those. Do not quote the fixture as capacity planning.

Memory scales with what the process does. A 20-line health handler at about 17 MiB does not predict a Java API with Hibernate. If your service needs 1 GB, fifty of them do not fit because a stub bench said 1.63 GiB.

The agent test is stricter than the human test

A human can maintain a messy Compose file through folklore. An agent cannot. It will regenerate the Dockerfile, drift the Tiltfile, and "fix" nginx until the health check is a lie.

The useful Flisk behavior is drift control. You own service.json. The CLI owns .autogenerated/. flisk config verify tells you when those generated files no longer match what the CLI would write. That is a small command with a large effect: the agent has a spec, and you have a diff when the spec was ignored.

Scaffolding follows the same idea.

flisk resource bot --type agent --stack shop --yes
flisk resource tools-mcp --type mcp --stack shop --yes
flisk up shop

The agent framework still owns prompts, tool calls, and retries. Flisk owns the local process, the checkpoint volume, the MCP server route, Postgres, and the gateway. If you do not have that second problem, you do not need this CLI just because you use an agent.

A pilot that can fail in a day

Do not migrate the monorepo. Pick one stack that already hurts.

Run flisk doctor. If Docker or Tilt is missing, the tool is not your bottleneck.
Add service.json beside one existing service. Bring-your-own is a documented path. You do not have to accept the Bun/TypeScript skeleton.
flisk up that-stack --dry-run. Read the URL list with the person who owns the Compose file.
Start it. Hit /health. Change a file. Confirm Tilt updates the container instead of you rebuilding by hand.
Stop if the generated files fight a Dockerfile you must keep byte-for-byte. Gradual adoption exists. A rewrite disguised as a pilot does not.

Windows note, because it wastes the first hour: native Windows can inspect (version, doctor, up --dry-run). Starting the stack needs Ubuntu on WSL2.

What you should not put in the adoption slide

"Replaces Kubernetes." It does not. Production stays on Helm.
"Saves five hours a week." Their own site says the calculator is arithmetic on your inputs, and the five-hour starting value is an editable input, not a measurement.
"Onboarding drops from three days to minutes." Designed for that. Not measured on a hiring cohort.
"Runs 100 production services on a MacBook." Runs 100 health stubs in a bench. Different sentence.

The fit, in one line

Flisk is too big for a Compose file that already fits on one screen, and too small to be your platform team. It fits the stack that has outgrown one file and has not earned a local cluster.