feat(presets): replace the nixpacks build engine with autopack

[dviejokfs]

Replaces Nixpacks with autopack as the build engine. The nixpacks* preset slugs stay exactly where they are — only what runs underneath them changed.

Why now

nixpacks 1.41.0 is the latest published version and pulls two advisories that have no upstream fix:

Advisory	Crate	Path
RUSTSEC-2023-0018	remove_dir_all 0.5.3	nixpacks → tempdir 0.3.7 → remove_dir_all
GHSA-8wf9-4rjw-8j9r	serde_with 2.3.3	nixpacks → serde_with (2.3.3 is the last 2.x ever published; the fix landed in 3.21.0)

Both were carried as documented, reachability-analysed exceptions in the root Cargo.toml because there was nothing to upgrade to. Dropping the dependency is the only thing that clears them.

Verified — cargo audit before and after:

before: 4 vulnerabilities (protobuf, rsa, remove_dir_all, serde_with)
after:  2 vulnerabilities (protobuf, rsa)

The two exception blocks are deleted rather than reworded.

This is the same pair of advisories #513 set out to fix by vendoring a nixpacks fork. That PR does clear them and is a legitimate approach; this one removes the dependency instead of maintaining a fork of it.

Compatibility is the constraint

Existing projects have preset = 'nixpacks' and a NixpacksConfig persisted against them. A deployment of one of those has to keep working with nobody touching anything:

• every nixpacks* slug still resolves, with the same stored_preset and the same stored config shape;
• a persisted nixpacks_config TOML is still honoured — autopack reads the Nixpacks schema in compatibility mode, and surfaces anything it could not translate as a warning instead of dropping it silently;
• a stored provider still forces that language, so a polyglot repo pinned to python does not quietly start building as node because detection order differs.

Labels move from Nixpacks (Python) to Autopack (Python). Slugs, which are persisted, do not move.

Two behaviour changes worth review

A project that cannot be planned now fails loudly. The old fallback emitted FROM alpine + COPY . . with no CMD — that builds, pushes, deploys, and then the container exits immediately with nothing useful in the log. It now emits a Dockerfile that exit 1s with the actual reason.

Autopack's Dockerfiles require BuildKit (cache and secret mounts). build_image.rs already sets use_buildkit: true, so the deployment path is fine. temps-cli build defaults it to false, and a classic-builder parse error points at a generated line the user never wrote — so that case is now refused by name up front. Worth a look: whether temps build should just default to BuildKit instead.

Tests: build it, run it, ask it for a page

crates/temps-presets/tests/starters.rs takes every starter from gotempsh/temps-examples, renders it through the real AutopackPreset the pipeline uses, docker builds it, runs it, and requests a page. The existing unit tests assert on generated Dockerfile text, which cannot tell a working build from a plausible-looking one.

It also checks the two properties that are invisible until they bite:

• it answers on $PORT — what the proxy connects to, and nothing else checks it;
• it stops on SIGTERM rather than waiting out the kill timeout. A container that ignores SIGTERM turns every redeploy into a hard kill of in-flight requests.

Result: 23 of 25 starters pass end to end locally (dockerfile is excluded — it exists to exercise the Dockerfile preset).

.github/workflows/starters.yml runs them as a matrix, one job per starter, plus nightly (the starters live in another repo, so a green PR here can still break later).

The two that don't pass

They run in a separate always-green report job rather than as required checks — a red required check everyone learns to ignore is worse than no check.

• java/spring-boot — Spring deduces a REACTIVE application type from a classpath that only has spring-boot-starter-web, then fails for want of a ReactiveWebServerFactory. The boot jar is selected correctly (the -plain.jar exclusion works) and the app does start, so this is not jar selection. Not yet root-caused.
• rust/actix — ignores SIGTERM; docker stop waits the full grace period and SIGKILLs. Actix's default graceful-shutdown timeout outlives the stop timeout.

One finding that belongs in temps-examples

ruby/rails, python/django, php/laravel and dotnet/web initially failed. All four ship a nixpacks.toml pinning a nixpacks-specific start command, and autopack's compatibility mode honours them faithfully:

Starter	Pinned command	What happens
ruby/rails	rails server ...	no bundle exec, so rails is not on PATH — exec: rails: not found
python/django	manage.py migrate && gunicorn ...	migrate fails: settings.DATABASES is improperly configured
php/laravel	php artisan serve	dev server; also pins php8.3-pgsql which does not resolve
dotnet/web	dotnet run	needs the SDK, which the runtime image does not carry

All four pass once the nixpacks.toml is removed — autopack's own providers already emit bundle exec rails server, gunicorn, FrankenPHP and dotnet <assembly>.dll correctly. Autopack already warns about three of these four via its risky-start-command check.

Those files are nixpacks-specific tuning and should go once nixpacks does. That's a change to gotempsh/temps-examples#12, not to this PR — this PR's matrix will stay red on those four until it lands.

Verification

• cargo check --workspace --lib — clean
• cargo test -p temps-presets --lib — 197 passed, 0 failed
• cargo clippy --all-targets -- -D warnings on the touched crates — clean
• cargo audit — 2 advisories cleared, confirmed above
• cargo tree -p temps-presets | grep nixpacks — no match; gone from Cargo.lock entirely

Not done

autopack-* are pinned to a commit on the public repo, not a released tag — a build plan changing under a release would change what every project's image contains with nothing here moving. Worth deciding whether to cut a tag before merge.

[github-actions]

📓 Changelog preview

This is what your commits will add to the generated CHANGELOG.md at release time (via git-cliff). Do not edit CHANGELOG.md by hand — it is generated from your Conventional Commit messages.

## [Unreleased]

### Added

- **presets:** Replace the nixpacks build engine with autopack
- **web:** Add the autopack preset icon

### CI

- Drop the temporary starters branch pin

### Fixed

- **ci:** Point the starters job at the branch that carries them
- **presets:** Stop the Nixpacks TOML validation error echoing the config

### Refactor

- **web:** Open the autopack icon's lid into a chevron

### Testing

- **ci:** Gate on rust/actix, which passes

[dviejokfs]

CI green — and two corrections to the description above

All 24 starter jobs pass. Run 30823442411

Two things in the original description were wrong:

1. I understated the CI dependency. I wrote that four jobs would stay red pending gotempsh/temps-examples#12. It was all of them — examples/starters does not exist on that repo's default branch at all, so every job panicked in 0.03s on the missing directory, before Docker was ever invoked. Fixed two ways: the checkout now pins ref: feat/language-starters (marked TEMPORARY — it must come out when #12 merges), and the panic now distinguishes "the variable is unset" from "the directory isn't there", which is what cost a full run to diagnose.

2. rust/actix is not failing. I listed it as known-failing on the strength of a local run where it ignored SIGTERM and docker stop had to SIGKILL it. On Linux CI it passes cleanly in 104s with the SIGTERM check included — the failure was a Docker Desktop artefact. It is now in the blocking matrix, because a passing starter parked in a report-only job is not actually gated.

The four nixpacks.toml files that pinned broken start commands were removed on the #12 branch (gotempsh/temps-examples@53cd57f). flask, fastapi and php/vanilla keep theirs deliberately — they pin correct commands and are the CI coverage for reading a nixpacks.toml at all.

Still failing, by design not blocking

java/spring-boot, in an always-green report-only job. Spring deduces a REACTIVE application type from a classpath that only carries spring-boot-starter-web, then fails for want of a ReactiveWebServerFactory. The boot jar is selected correctly (the -plain.jar exclusion works) and the app does start, so it is not jar selection. Not root-caused.

Merge order

This PR cannot go in before gotempsh/temps-examples#12, and the ref: pin has to be deleted in the same breath — otherwise the job keeps testing a branch instead of what main ships.