Step 3: process types on a platform¶

A platform runs each process of the layout, and restarts it if it dies; inside each process, the runtime supervises the services. myxo export writes each platform's files from the same layout:

The process named web serves the public port, $PORT. On Kubernetes, the manifests set MYXO_URL_WEB to the web process's service and MYXO_BIND to 0.0.0.0, which override the layout's default Unix socket.

On Kubernetes, an installation takes an image, a secret, the migrations, then the application. The image builds from the root of the uv project, here guestbook/, and the cluster must be able to pull it. DATABASE_URL must be set for the export, since pods cannot share SQLite, and it is now the address the pods reach, which may differ from the one your machine uses. The secret holds the variables that env.example lists:

$ export DATABASE_URL=postgresql://guestbook:secret@db.example.org/guestbook
$ IMAGE=registry.example.org/guestbook:1
$ myxo export layouts/app.toml docker --name guestbook --out k8s
$ docker build -f k8s/Dockerfile -t $IMAGE .
$ docker push $IMAGE
$ myxo export layouts/app.toml kubernetes --name guestbook --image $IMAGE --out k8s
$ kubectl create secret generic guestbook-env --from-literal=DATABASE_URL=$DATABASE_URL
$ kubectl apply -f k8s/migrate.json
$ kubectl wait --for=condition=complete job/guestbook-migrate
$ kubectl apply -f k8s/app.json
$ kubectl rollout status deployment/guestbook-web deployment/guestbook-worker

The manifests include a service named guestbook, on port 80 inside the cluster, in front of the web process. Reaching it from outside is yours to set up, with an ingress or a NodePort service, as for any application on the cluster. Moving from myxo up to the cluster means a short interruption: stop the old processes, apply app.json, and point the public address at the new service.

Next, read step 4, replicas.