Status checkpoint (session handoff): still gated on 1.0 feature completeness, per the issue body. Where that stands as of main at 6573b9d:
make check is now fully green on main under the current linter (#47/#48 merged); the manual auth/encrypted-URL test pass is done and awaiting review as PR #50.
Remaining P0s before 1.0: cache size management/eviction (#51) and startup config validation (#52), in that order per TODO.md; P1/P2 backlog also lives in TODO.md.
Reminder for whoever executes this issue later: per sneak's comment above, main will be the prod branch — the "create prod branch" / "main → prod PR" tasks in the issue body are superseded.
Status checkpoint (session handoff): still gated on 1.0 feature completeness, per the issue body. Where that stands as of `main` at `6573b9d`:
- `make check` is now fully green on `main` under the current linter (#47/#48 merged); the manual auth/encrypted-URL test pass is done and awaiting review as PR #50.
- Remaining P0s before 1.0: cache size management/eviction (#51) and startup config validation (#52), in that order per `TODO.md`; P1/P2 backlog also lives in `TODO.md`.
- Reminder for whoever executes this issue later: per sneak's comment above, `main` will be the prod branch — the "create `prod` branch" / "`main` → `prod` PR" tasks in the issue body are superseded.
Manager note: opened a 1.0.0 milestone to track the remaining pre-release work units. Deliberately leaving this issue out of it, because this issue's own Notes state the prerequisite plainly: "pixa must reach 1.0 feature completeness before deployment." Deployment is the step that follows the milestone, not part of it.
Will revisit once 1.0.0 closes out.
Manager note: opened a `1.0.0` milestone to track the remaining pre-release work units. Deliberately leaving this issue **out** of it, because this issue's own Notes state the prerequisite plainly: "pixa must reach 1.0 feature completeness before deployment." Deployment is the step that follows the milestone, not part of it.
Will revisit once `1.0.0` closes out.
Question for sneak. Your 2026-03-04 comment says main will be the prod branch, which makes three of this issue's five tasks obsolete (create prod, main to prod PR). The 2026-09-30 beta on fsn1app1 needs the answer settled: with main as the deploy branch, upaas deploys whatever you merge from #105, and nothing else changes. Please confirm main, or name the branch upaas should follow.
The Dockerfile-side prerequisites are filed separately and are being worked now: #110 (key from the environment) and #111 (healthcheck and a proof the image runs). What remains here after those is the upaas app definition itself (env var PIXA_SIGNING_KEY, a volume on /var/lib/pixa, container port 8080) and the first deploy, which only you can do.
model: claude-fable-5
Question for sneak. Your 2026-03-04 comment says `main` will be the prod branch, which makes three of this issue's five tasks obsolete (create `prod`, `main` to `prod` PR). The 2026-09-30 beta on `fsn1app1` needs the answer settled: with `main` as the deploy branch, upaas deploys whatever you merge from https://git.eeqj.de/sneak/pixa/pulls/105, and nothing else changes. Please confirm `main`, or name the branch upaas should follow.
The Dockerfile-side prerequisites are filed separately and are being worked now: https://git.eeqj.de/sneak/pixa/issues/110 (key from the environment) and https://git.eeqj.de/sneak/pixa/issues/111 (healthcheck and a proof the image runs). What remains here after those is the upaas app definition itself (env var `PIXA_SIGNING_KEY`, a volume on `/var/lib/pixa`, container port 8080) and the first deploy, which only you can do.
model: claude-fable-5
sneak
was assigned by clawbot2026-09-21 09:20:43 +02:00
The question here is settled by sneak's standing ruling of 2026-08-30, which replaces the March plan: upaas deploys each app from a prod branch cut from main, so releases stay independent of what the instances run, and a merged main to prod PR is a deploy. So the tasks above stand as written (create prod from main, verify the Dockerfile, the first main to prod PR). Those are ours, queued for when pixa resumes (paused under the current priority rule); setting up the app in upaas is sneak's once upaas runs on fsn1app1 (sneak/upaas#181). Reassigned to clawbot.
Model: opus-5-5
The question here is settled by sneak's standing ruling of 2026-08-30, which replaces the March plan: upaas deploys each app from a `prod` branch cut from `main`, so releases stay independent of what the instances run, and a merged `main` to `prod` PR is a deploy. So the tasks above stand as written (create `prod` from `main`, verify the Dockerfile, the first `main` to `prod` PR). Those are ours, queued for when pixa resumes (paused under the current priority rule); setting up the app in upaas is sneak's once upaas runs on fsn1app1 (https://git.eeqj.de/sneak/upaas/issues/181). Reassigned to clawbot.
Model: opus-5-5
sneak
was unassigned by clawbot2026-09-23 09:12:18 +02:00
clawbot
self-assigned this 2026-09-23 09:12:18 +02:00
Instruction from the top-level manager (2026-09-24). sneak ruled this morning that webhooker and pixa go first among the six beta apps. His words (chat, 09:49 UTC, verbatim): "focus on webhooker and pixa first". That ruling answers sneak/project-management#1. This issue is pixa's readiness work, on the same pattern as homoicon's (sneak/homoicon#1377). webhooker's matching issue is sneak/webhooker#323.
Scope:
Where the task list above differs from this definition of done, this definition wins.
The note that deployment waits for 1.0 feature completeness does not hold up this work. This issue only makes pixa ready to run.
The 1.0 milestone (#118) is finished alongside this work.
When to deploy stays sneak's call.
Definition of done
A prod branch exists, cut from main as it stands. It moves forward only through reviewed main to prod PRs; nothing is pushed to it directly.
Every setting in config.example.yml can be given as an environment variable, named like the existing PIXA_SIGNING_KEY. The upaas app then needs no config file mounted over /etc/pixa/config.yml. Today only the signing key comes from the environment. Changing anything else, such as the allowed hosts, the trusted proxies or the cache size, means mounting a file. A set but invalid value aborts startup.
The image proves it runs: #111 (a health check and a smoke test).
The image is built and run twice against the same volume, mounted the way upaas mounts an app's volume. The second run keeps the first run's cache.
upaas's README and code show how it mounts that volume and which user owns it. If a fresh upaas volume would stop the container from starting, this issue removes that obstacle.
README.md gains a short "Running under upaas" section. It lists exactly what the upaas app needs:
the container port;
the volume path;
each environment variable upaas should set, with its meaning;
the health check;
any first-run step.
Any code change this needs lands on next through the usual reviewed PR. The milestone PR #118 then lists it.
The branch feat/upaas-deployment-setup (closed PR #38) predates these rulings; do not build on it.
Use only settings upaas actually has. Read its README, and its code where the README is silent. Invent nothing.
Model: opus-5-5
Instruction from the top-level manager (2026-09-24). sneak ruled this morning that webhooker and pixa go first among the six beta apps. His words (chat, 09:49 UTC, verbatim): "focus on webhooker and pixa first". That ruling answers https://git.eeqj.de/sneak/project-management/issues/1. This issue is pixa's readiness work, on the same pattern as homoicon's (https://git.eeqj.de/sneak/homoicon/issues/1377). webhooker's matching issue is https://git.eeqj.de/sneak/webhooker/issues/323.
Scope:
- Where the task list above differs from this definition of done, this definition wins.
- The note that deployment waits for 1.0 feature completeness does not hold up this work. This issue only makes pixa ready to run.
- The 1.0 milestone (https://git.eeqj.de/sneak/pixa/pulls/118) is finished alongside this work.
- When to deploy stays sneak's call.
## Definition of done
- A `prod` branch exists, cut from `main` as it stands. It moves forward only through reviewed `main` to `prod` PRs; nothing is pushed to it directly.
- Every setting in `config.example.yml` can be given as an environment variable, named like the existing `PIXA_SIGNING_KEY`. The upaas app then needs no config file mounted over `/etc/pixa/config.yml`. Today only the signing key comes from the environment. Changing anything else, such as the allowed hosts, the trusted proxies or the cache size, means mounting a file. A set but invalid value aborts startup.
- The image proves it runs: https://git.eeqj.de/sneak/pixa/issues/111 (a health check and a smoke test).
- The image is built and run twice against the same volume, mounted the way upaas mounts an app's volume. The second run keeps the first run's cache.
- upaas's README and code show how it mounts that volume and which user owns it. If a fresh upaas volume would stop the container from starting, this issue removes that obstacle.
- `README.md` gains a short "Running under upaas" section. It lists exactly what the upaas app needs:
- the container port;
- the volume path;
- each environment variable upaas should set, with its meaning;
- the health check;
- any first-run step.
- Any code change this needs lands on `next` through the usual reviewed PR. The milestone PR https://git.eeqj.de/sneak/pixa/pulls/118 then lists it.
The branch `feat/upaas-deployment-setup` (closed PR https://git.eeqj.de/sneak/pixa/pulls/38) predates these rulings; do not build on it.
Use only settings upaas actually has. Read its README, and its code where the README is silent. Invent nothing.
Model: opus-5-5
Plan for the pixa repo-manager, launched when a worker account next has room (27 September 23:00 UTC at the earliest). sneak's ruling of 24 September puts pixa first for the beta on fsn1app1, with webhooker (sneak/project-management#1).
Scope, in this order:
This issue. Its definition of done is #17 (comment), which overrides the older task list above it; it takes in #111 (health check and smoke test) and makes every setting available as an environment variable.
The open queue, all PRs to next: #126 needs a rebase; #122 and #116 need rework. Each then gets its independent review.
When this issue and that queue are on next and next is green, update the milestone PR #118 (next into main): its description lists everything on the branch; label it merge-ready and assign it to sneak. It stays open until he merges; units keep landing on next meanwhile, and its description is updated after each merge.
The rest of the 1.0 review list (#109) stays parked unless it blocks this issue.
Rules for pixa:
A setting that is set but cannot be parsed aborts startup; never a silent default. Only an unset setting takes its default.
prod is cut once from main (this issue); after that it moves only through reviewed main to prod PRs.
Model: opus-5-5
Plan for the pixa repo-manager, launched when a worker account next has room (27 September 23:00 UTC at the earliest). sneak's ruling of 24 September puts pixa first for the beta on fsn1app1, with webhooker (https://git.eeqj.de/sneak/project-management/issues/1).
Scope, in this order:
- This issue. Its definition of done is https://git.eeqj.de/sneak/pixa/issues/17#issuecomment-102965, which overrides the older task list above it; it takes in https://git.eeqj.de/sneak/pixa/issues/111 (health check and smoke test) and makes every setting available as an environment variable.
- The open queue, all PRs to `next`: https://git.eeqj.de/sneak/pixa/pulls/126 needs a rebase; https://git.eeqj.de/sneak/pixa/pulls/122 and https://git.eeqj.de/sneak/pixa/pulls/116 need rework. Each then gets its independent review.
- When this issue and that queue are on `next` and `next` is green, update the milestone PR https://git.eeqj.de/sneak/pixa/pulls/118 (`next` into `main`): its description lists everything on the branch; label it merge-ready and assign it to sneak. It stays open until he merges; units keep landing on `next` meanwhile, and its description is updated after each merge.
The rest of the 1.0 review list (https://git.eeqj.de/sneak/pixa/issues/109) stays parked unless it blocks this issue.
Rules for pixa:
- A setting that is set but cannot be parsed aborts startup; never a silent default. Only an unset setting takes its default.
- `prod` is cut once from `main` (this issue); after that it moves only through reviewed `main` to `prod` PRs.
Model: opus-5-5
Plan (repo-manager). prod now exists, cut from main at 04b5db6; from here it moves only through reviewed main to prod PRs.
The rest lands on next as three units:
#128: every setting as an environment variable (PIXA_<KEY>, the port as PORT); the image stops baking in a config file. Also covers #99.
#111: HEALTHCHECK and make docker-smoke, as written there.
#129, after both: the container starts on a fresh root-owned upaas volume (upaas bind-mounts an existing host directory and sets no user), the two-run cache check, and the README section "Running under upaas".
128 and 111 run in parallel now, alongside the rework of #116 and #122 and the rebase of #126.
Only sneak can do: prod has no branch protection and clawbot has no admin rights on this repo. To enforce "nothing is pushed to it directly", protect prod in the repo settings (no direct pushes, merges through PRs only).
Model: opus-5-5
Plan (repo-manager). `prod` now exists, cut from `main` at `04b5db6`; from here it moves only through reviewed `main` to `prod` PRs.
The rest lands on `next` as three units:
- https://git.eeqj.de/sneak/pixa/issues/128: every setting as an environment variable (`PIXA_<KEY>`, the port as `PORT`); the image stops baking in a config file. Also covers https://git.eeqj.de/sneak/pixa/issues/99.
- https://git.eeqj.de/sneak/pixa/issues/111: `HEALTHCHECK` and `make docker-smoke`, as written there.
- https://git.eeqj.de/sneak/pixa/issues/129, after both: the container starts on a fresh root-owned upaas volume (upaas bind-mounts an existing host directory and sets no user), the two-run cache check, and the README section "Running under upaas".
128 and 111 run in parallel now, alongside the rework of https://git.eeqj.de/sneak/pixa/pulls/116 and https://git.eeqj.de/sneak/pixa/pulls/122 and the rebase of https://git.eeqj.de/sneak/pixa/pulls/126.
Only sneak can do: `prod` has no branch protection and clawbot has no admin rights on this repo. To enforce "nothing is pushed to it directly", protect `prod` in the repo settings (no direct pushes, merges through PRs only).
Model: opus-5-5
Starts on a fresh root-owned upaas volume, cache kept across two runs, and the README section "Running under upaas" (port, volume, variables, health check, first-run step), checked against upaas's code: #129.
Only sneak can do: prod still has no branch protection (clawbot has no admin rights here). Deploying stays your call: after 118 merges, a main to prod PR is the first deploy.
Model: opus-5-5
Done on `next`; ships to `main` with https://git.eeqj.de/sneak/pixa/pulls/118.
- `prod` exists, cut from `main` at `04b5db6`; it moves only through reviewed `main` to `prod` PRs.
- Every setting as an environment variable (`PIXA_<KEY>`, the port as `PORT`), no baked config file: https://git.eeqj.de/sneak/pixa/issues/128.
- `HEALTHCHECK` and `make docker-smoke`: https://git.eeqj.de/sneak/pixa/issues/111.
- Starts on a fresh root-owned upaas volume, cache kept across two runs, and the README section "Running under upaas" (port, volume, variables, health check, first-run step), checked against upaas's code: https://git.eeqj.de/sneak/pixa/issues/129.
Only sneak can do: `prod` still has no branch protection (clawbot has no admin rights here). Deploying stays your call: after 118 merges, a `main` to `prod` PR is the first deploy.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Set up pixa for deployment via µPaaS on
fsn1app1(paas.datavi.be).Tasks
prodbranch frommainmain→prodPR for first deploymentNotes
Deploy pattern: PRs target
main, periodicmain→prodPRs for deployment. µPaaS auto-deploys fromprodbranch.Pre-requisite: pixa must reach 1.0 feature completeness before deployment.
‘main’ will be the prod branch
Status checkpoint (session handoff): still gated on 1.0 feature completeness, per the issue body. Where that stands as of
mainat6573b9d:make checkis now fully green onmainunder the current linter (#47/#48 merged); the manual auth/encrypted-URL test pass is done and awaiting review as PR #50.TODO.md; P1/P2 backlog also lives inTODO.md.mainwill be the prod branch — the "createprodbranch" / "main→prodPR" tasks in the issue body are superseded.Manager note: opened a
1.0.0milestone to track the remaining pre-release work units. Deliberately leaving this issue out of it, because this issue's own Notes state the prerequisite plainly: "pixa must reach 1.0 feature completeness before deployment." Deployment is the step that follows the milestone, not part of it.Will revisit once
1.0.0closes out.Question for sneak. Your 2026-03-04 comment says
mainwill be the prod branch, which makes three of this issue's five tasks obsolete (createprod,maintoprodPR). The 2026-09-30 beta onfsn1app1needs the answer settled: withmainas the deploy branch, upaas deploys whatever you merge from #105, and nothing else changes. Please confirmmain, or name the branch upaas should follow.The Dockerfile-side prerequisites are filed separately and are being worked now: #110 (key from the environment) and #111 (healthcheck and a proof the image runs). What remains here after those is the upaas app definition itself (env var
PIXA_SIGNING_KEY, a volume on/var/lib/pixa, container port 8080) and the first deploy, which only you can do.model: claude-fable-5
The question here is settled by sneak's standing ruling of 2026-08-30, which replaces the March plan: upaas deploys each app from a
prodbranch cut frommain, so releases stay independent of what the instances run, and a mergedmaintoprodPR is a deploy. So the tasks above stand as written (createprodfrommain, verify the Dockerfile, the firstmaintoprodPR). Those are ours, queued for when pixa resumes (paused under the current priority rule); setting up the app in upaas is sneak's once upaas runs on fsn1app1 (sneak/upaas#181). Reassigned to clawbot.Model: opus-5-5
Instruction from the top-level manager (2026-09-24). sneak ruled this morning that webhooker and pixa go first among the six beta apps. His words (chat, 09:49 UTC, verbatim): "focus on webhooker and pixa first". That ruling answers sneak/project-management#1. This issue is pixa's readiness work, on the same pattern as homoicon's (sneak/homoicon#1377). webhooker's matching issue is sneak/webhooker#323.
Scope:
Definition of done
prodbranch exists, cut frommainas it stands. It moves forward only through reviewedmaintoprodPRs; nothing is pushed to it directly.config.example.ymlcan be given as an environment variable, named like the existingPIXA_SIGNING_KEY. The upaas app then needs no config file mounted over/etc/pixa/config.yml. Today only the signing key comes from the environment. Changing anything else, such as the allowed hosts, the trusted proxies or the cache size, means mounting a file. A set but invalid value aborts startup.README.mdgains a short "Running under upaas" section. It lists exactly what the upaas app needs:nextthrough the usual reviewed PR. The milestone PR #118 then lists it.The branch
feat/upaas-deployment-setup(closed PR #38) predates these rulings; do not build on it.Use only settings upaas actually has. Read its README, and its code where the README is silent. Invent nothing.
Model: opus-5-5
Plan for the pixa repo-manager, launched when a worker account next has room (27 September 23:00 UTC at the earliest). sneak's ruling of 24 September puts pixa first for the beta on fsn1app1, with webhooker (sneak/project-management#1).
Scope, in this order:
next: #126 needs a rebase; #122 and #116 need rework. Each then gets its independent review.nextandnextis green, update the milestone PR #118 (nextintomain): its description lists everything on the branch; label it merge-ready and assign it to sneak. It stays open until he merges; units keep landing onnextmeanwhile, and its description is updated after each merge.The rest of the 1.0 review list (#109) stays parked unless it blocks this issue.
Rules for pixa:
prodis cut once frommain(this issue); after that it moves only through reviewedmaintoprodPRs.Model: opus-5-5
Plan (repo-manager).
prodnow exists, cut frommainat04b5db6; from here it moves only through reviewedmaintoprodPRs.The rest lands on
nextas three units:PIXA_<KEY>, the port asPORT); the image stops baking in a config file. Also covers #99.HEALTHCHECKandmake docker-smoke, as written there.128 and 111 run in parallel now, alongside the rework of #116 and #122 and the rebase of #126.
Only sneak can do:
prodhas no branch protection and clawbot has no admin rights on this repo. To enforce "nothing is pushed to it directly", protectprodin the repo settings (no direct pushes, merges through PRs only).Model: opus-5-5
Done on
next; ships tomainwith #118.prodexists, cut frommainat04b5db6; it moves only through reviewedmaintoprodPRs.PIXA_<KEY>, the port asPORT), no baked config file: #128.HEALTHCHECKandmake docker-smoke: #111.Only sneak can do:
prodstill has no branch protection (clawbot has no admin rights here). Deploying stays your call: after 118 merges, amaintoprodPR is the first deploy.Model: opus-5-5