AppTown v1.0.0-rc.13

Flokkit AppTown v1.0.0-rc.13

RC13 is a full polish pass of the web interface: Services now has its own page,
separate from Integrations, status words say what is known and what is not,
lights in the top bar show confirmed problems, and every page has a short
description and help. Packs become a project's only way-of-working choice:
per-project workflow selection is gone and scheduled maintenance is a pack a
project adopts. Status and Attention can now be trusted: readings are taken in
background checks, kept across restarts, aged by what they measure, and counted
one per row shown. It includes all changes since RC12. Several changes are
breaking; read "Breaking changes" before upgrading. Take matching database and
file backups before upgrading, as described in the
upgrade guide.

Breaking changes

Ways of working (packs are the only choice):

• Per-project workflow selection is removed. Migration 200 drops the stored
  workflow ticks; nothing is migrated or kept. Every project can now run every
  core and extra library workflow plus the workflows its adopted packs supply,
  subject to the usual authority and policy checks, so a workflow that was
  unticked is now available. PUT /api/v1/projects/{slug}/lanes is removed
  (404) and so is the project:configure-workflow capability.
  GET /api/v1/projects/{slug}/lanes is read-only and drops selected.
• Scheduled workflows run only from packs that declare them. A workflow runs
  on its schedule only when an adopted pack version lists it under schedules.
  Making a workflow available never schedules it. After upgrading nothing is
  scheduled until a project adopts such a pack version. The stock server-base
  and frontend-only packs no longer carry dependency-uplift; the new
  dependency-updates pack supplies it and declares
  schedules: [dependency-uplift]. Operator step: adopt dependency-updates
  on every project that should keep its monthly dependency updates. New
  projects have it ticked by default and people can untick it.
• System workflows cannot be started by hand. Starting land,
  adopt-integration, retire-integration or another AppTown-run workflow
  through change admission, MCP create_change / start_change_lane or
  POST /changes/{id}/runs is refused (HTTP 422, an MCP tool error), also for
  administrators. Landing goes through the landing request and restart paths.
  apptown adopt uses the integration wiring endpoint; apptown retire uses
  the new POST /api/v1/projects/{slug}/integrations/{capability}/retire, which
  needs an attached integration plus integration configuration and change and
  run permissions, and offers to detach afterwards.
• Pack pull plans and results drop keptReferenced and deprecated; they
  report workflow availability changes instead. The workflow library drops
  usedBy and its usage line. Policy reports leave out withdrawn workflows
  unless an adopted pack still names them.

Models:

• Per-project model overrides are removed. Models are chosen only by slot and
  profile; a project that needs different models gets its own profile.
  Migration 198 deletes every per-project model row. Move any per-project
  mapping you rely on to a profile before upgrading.
  PUT /api/v1/model-slots with project is refused (400) and
  GET /api/v1/model-slots no longer returns overrides. An eval copy takes its
  arm's profile.
• Profiles have four basic choices. They are Main · strong (main-strong),
  Main · fast (main-fast), Second opinion · strong (secondary-strong) and
  Second opinion · fast (secondary-fast).
  GET /api/v1/model-slots marks them with base and lists them first.
  Migration 199 moves every explicit fast cell to the fast main choice, keeping its
  profile, pattern and time; set fast again only as an advanced task override.
  The stock fallbacks change review to secondary-strong and fast to
  the fast main choice where they still hold the stock value. Rows an operator edited
  are left alone. Guidance checks, fleet conformance checks and new eval judges
  ask for secondary-fast directly, so editing the fast task no longer
  changes them. Stock chains resolve to the same models as before; where an
  operator edited the fast fallback and a profile set fast, fast and
  scout now follow the edited row.
• The basic choices are renamed: default is now main-strong and
  primary-fast is now main-fast. Migration 201 renames the stored settings
  and both ends of every fallback row, keeping models, profiles and times. There
  are no aliases: API calls, workflows and configuration that name default or
  primary-fast must use the new names. PUT /api/v1/model-slots refuses the
  old names (400), and a model request naming one fails with an error that lists
  the current names. Stored workflow model requests are not rewritten: before
  upgrading, find any that name the old choices and edit them by hand. Past
  run records keep the names they ran with, so per-row token spend on the
  profile page reads low for Main · strong and Main · fast until new runs add up.
• A profile is read in full before standard. A task that a profile leaves
  unset now follows its fallback chain within that profile first, and only then
  standard's. A profile's basic choice therefore beats a task set only in
  standard: on a profile that sets Main · strong, review and the fast tasks use
  that profile's model rather than standard's task setting. standard itself is
  unchanged.

Status, checks and Attention:

• Status is read from background checks. Inventory, host capacity, AppTown
  and worker disks, backup protection, integrations, targets, previews and
  deployment details are checked at start and every five minutes. Opening a
  page no longer contacts hosts or providers. The Infrastructure Refresh action
  is removed and GET /api/v1/infrastructure?refresh=1 has no effect. Inventory
  responses replace refreshing with invalidated (the reading predates
  AppTown's latest act at that target). Preview start, restart and stop, and
  deployment actions, repairs and backups, queue a check of what they touched.
• Readings survive restarts and age by what they measure (migrations 194 to
  196). Machine totals stay valid for seven days. Live readings are fresh for 15
  minutes, then "last seen" with their age, and unknown after six hours. A
  failed check keeps the last good values and their time. A pending first check
  raises no Attention item.
• Attention counts one per row it shows, with the same "<n> to fix ·
  <m> not known" wording in its header and on Home. Only integrations with an
  automatic check and a failed latest result count. Package registries,
  scanners that run inside the app image and other kinds with no automatic check
  read "no automatic check". A Test connection result is kept as the last
  state and marked old after 15 minutes. Background target checks need two
  failures in a row to mark a target unreachable.
• A check that could not give an answer is "not known", not a problem. A
  check that could not start, a failed model call or a missing model answer is
  recorded as an evaluation error and shown as not known with its reason.
  Routine deferrals (no standing deployment, no cached image, no evaluator) stay
  not yet assessed and raise nothing. With no model available, AI rubric checks
  read not known. Required checks that cannot answer still stop the gate.
• Display words change. A ready deployment target reads working (was
  passed). Integration health adds not set up; GitLab with both settings
  empty is not set up, not failed, and a partly configured GitLab or Infisical
  is failed and names the missing setting. Disk warnings apply below 10% free on
  every disk; the former 40 GiB cap is gone. Attention item titles now name
  their host or app; do not match the old wording.
• Manual scanners may declare appliesTo. A tool check runs only where both
  the check and its scanner apply. The stock hadolint scanner declares build,
  so it no longer runs, or reports a missing Dockerfile, on static-only apps.
• Container registry checks sign in. Listings, saves and Test connection
  call GET /v2/ over HTTPS with the configured username and token, following a
  Bearer challenge only to a token service on the same domain. A registry that
  refuses the credentials now reads failed.

Projects, Home and pages:

• Project descriptions are generated. blurb on project creation (HTTP,
  MCP create_project, apptown new) is now the original request, kept in
  the project's history. AppTown writes a short description from it in the
  background with the fast model; with no model it stays empty. Migration 193
  keeps every existing description as written by a person, so it is not
  regenerated until someone clears it. Project responses add blurbSource and,
  on detail, originalRequest.
• GET /api/v1/projects?order=recent is removed (400). Use order=running
  or order=mine with limit and offset.
• The workflow catalogue moves from /workflow-library to /workflows,
  with no redirect. Update bookmarks.

Containers:

• Docker labels for people move to apptown.info.*. Containers, networks
  and volumes carry apptown.info.project and apptown.info.deployment;
  change previews carry apptown.info.project and apptown.info.change (the
  change title, cut at 120 bytes). apptown.deployment.name is no longer
  written, and the wrongly written <project>=<project> label is gone.
  Existing resources keep their old labels until they are recreated. AppTown
  reads none of these labels, so ownership and cleanup are unchanged; update any
  docker ps filters or display commands you use.

New and improved

• **Services and Integrations are se...

AppTown v1.0.0-rc.12

Flokkit AppTown v1.0.0-rc.12

RC12 removes machinery that nothing used, makes cleanup of leftover containers
the default, narrows what AppTown counts as its own at a deployment target, and
builds a release once, as a candidate, before its version tag exists. A project
can now adopt several packs. It includes all changes since RC11. Several changes are breaking; read
"Breaking changes" before upgrading. Take matching database and file backups
before upgrading, as described in the
upgrade guide.

Breaking changes

Startup and operation:

• Cleanup is on by default; -reap is removed. The periodic cleanup of step,
  service and chat containers and networks, unwatched previews and their kept
  builds, images, toolchain caches and finished workspaces now deletes instead
  of only logging. apptownd -disable-reap (APPTOWN_DISABLE_REAP=true) turns
  deletion off. A command line that still passes -reap stops apptownd;
  APPTOWN_REAP is no longer read. Remove both from service files, including a
  systemd drop-in that sets APPTOWN_REAP. Cleanup cannot tell two AppTowns'
  containers apart: give a second AppTown on the same Docker daemon its own
  daemon, or run both with -disable-reap.
• The update supervisor is removed. The -update-supervisor-socket flag is
  gone (passing it fails start-up), bin/apptown-update is no longer shipped and
  the managed supervisor guide is removed. The Updates page still checks signed
  release information and shows how to install a newer release.
  UPDATE-MANIFEST.json is format 2; builds before RC12 cannot read it and show
  the release check as failed or stale, so update those by hand once. The
  notification cache moves to <data>/release-checks; delete the old
  <data>/instance-updates folder.
• Host-process execution is removed. apptownd -agent-executor and
  -host-scripts are unknown flags and APPTOWN_AGENT_EXECUTOR and
  APPTOWN_HOST_SCRIPTS are not read. Agents and scripts run only in
  containers. A workflow that names an executor other than docker is refused
  when saved; a run admitted earlier with executor: local stops at that step.
• Private Docker is on by default. -no-private-docker is removed and
  APPTOWN_NO_PRIVATE_DOCKER is ignored. Use -private-docker=false
  (APPTOWN_PRIVATE_DOCKER=false). With a worker, docker: true steps and release
  builds run there without opting in.
• Docker's buildx plugin is required. AppTown no longer falls back to
  Docker's legacy builder when docker buildx version fails: the build is refused
  before anything is sent. Install docker-buildx-plugin beside the docker CLI
  AppTown runs (AppTown's published images include it). Check-image and
  agent-image builds now also require buildx and the daemon's own builder, as
  deployment builds already did.
• PostgreSQL major version is checked at start. AppTown supports a range of
  PostgreSQL majors for its own database, built in or -db-url (today 16 only).
  apptownd refuses to start on a server outside the range and names it.
  Backups and restores check the same range.
• Data folders from before 1.0.0-rc.9 are refused. Upgrade with RC9 to RC11
  first. Whole-AppTown restore accepts only backups taken by RC9 or later; an
  archive with linked or borrowed workspace Git metadata is refused. The
  data-folder layout 1-to-2 upgrade is removed; new installs write layout 2.

Backups:

• Whole-AppTown backups hold AppTown only. Built-in deployments are filled on
  restore from their own newest whole deployment backup. One whose data did not
  come back is kept out of automatic rebuilds (a new restore check, not-filled)
  so a restart does not start it on empty data; releasing it is the decision to
  start it without that data. The manifest no longer lists deployments.
• pg_dump runs in a pinned container, on AppTown's own Docker when it has
  one, otherwise on its worker. The host's pg_dump is no longer used. A
  -db-url database must be reachable from a container: a loopback host is
  refused. sslrootcert in -db-url is honoured; verify-ca and verify-full
  without one verify against the image's system roots. On a worker the gzipped
  dump is one result of at most 64 MiB; a larger one is refused. Backups with
  -no-local-docker need the worker and AppTown upgraded together. The first
  backup on a host pulls the pinned postgres image.
• scripts/apptown-db-backup.sh is removed from archives and the image. Take
  apptownd backup before upgrading; the upgrade guide describes rolling back from
  that archive.

Targets and deployments:

• Inventory counts only resources carrying this installation's mark. Every
  resource AppTown makes at a target carries the installation's id (a Docker label,
  a Portainer stack variable, an App Platform spec variable, a DigitalOcean database
  tag, or a private _apptown/instance object in a bucket-website bucket).
  Resources without the mark only confirm recorded deployments; only a marked
  resource that nothing records is reported as not accounted for or can be removed
  from the infrastructure page. Resources made by a person or script, such as the
  database AppTown runs on, are no longer listed. At each start AppTown marks
  managed database clusters and bucket-website buckets that deployment records
  name; Docker objects, Portainer stacks and App Platform apps gain the mark at
  their next release. A target kind with no inventory reader shows as unknown
  rather than an error.
• Health is judged one way. With no declared expect, a 4xx or 5xx answer at
  the health path is no longer ready on Docker and Portainer, for HTTP liveness
  probes, or in a restore rehearsal's sealed boot. An app whose health path
  answers 404 must fix the path or declare expect: 404. On App Platform a
  redirect at the health path now counts as ready (it is not followed).
• .forge/app.yaml is no longer read. Only .apptown/app.yaml at a commit
  is the app contract (a regular file, at most 1 MiB; links are refused). A commit
  whose contract is only at .forge/app.yaml reads as having none, which affects
  redeploying or restoring a release built from it.
• Resource limits are flattened to three levels: the deployment's override,
  else what the app declares for its profile, else AppTown's default. A pack can no
  longer declare resources; clears: [resources] is refused. An app part that
  declares no memory gets 512Mi at its next release. An unattended pack update from
  a publication that declared memory is refused.
• secretsDelivery and deploymentPolicy are removed. secretsDelivery is
  gone from target responses and the target page (migration 183). deploymentPolicy
  is refused when creating a deployment (400, unknown key) and no longer appears in
  deployment, tier, target-page or MCP get_project responses.
• Release setup and promoteAfter are removed. The apptown release-setup
  command, the route, imported setup state and the per-deployment promotion toggle
  are gone. Promotion permission is needed only for protected deployments;
  admitted releases keep their recorded requirement. The promoteAfter attribute
  is removed.
• Legacy Portainer confirmation is removed. Other Portainer targets without a
  recorded endpoint must be attached again. A deployment whose stored URL does not
  match the recorded hostname rule, or whose host another deployment claims, gets
  a new generated hostname at its next release.
• The storage-bindings routes are removed; the next deploy records the binding.

Ways of working (a project takes several packs):

• A project adopts one or more packs, none above another, and packs no longer
  include one another. Migration 192 drops the single primary pack name and
  pack inclusion. New receipts carry packs (sorted names, platform included)
  instead of pack; an old receipt's pack key is no longer read.
• Stock packs are reorganised. Retired (turned off at sync; a project on one
  keeps working until moved): go-small, node-fullstack, django-htmx,
  java-spring, rust-service and wordpress-bedrock. New: server-base,
  go, node, django, java, rust, wordpress, postgres, vite-react
  and server-rendered. rails and dotnet keep their names but hold only
  backend content, and their old contents clash with server-base. Guidance
  blocks withdrawn: frontend/vite-typescript and
  lang/selection/typescript-for-web (now frontend/vite-react),
  frontend/hypermedia-htmx (now frontend/server-rendered) and
  observability/error-reporting (its rules are in the errors integration's
  generated steering section). Starter folders take the backend pack names.
• Pack declarations lose includes, replaces, drops, clears and
  starter; saving one that has them is refused.
• Operator steps after upgrading. A release never recommends a stock version
  by itself: recommend the new versions of rails and dotnet (and of
  frontend-only, conventions-only, video-game and godot-3d), then move
  projects off the retired packs. Until then a project with a revision shows an
  adoption drift note (display only). Moving a project drops its own guidance
  additions. An uplift change opened before the upgrade and not landed cannot
  settle: it is closed as superseded when the project moves; open it again after. An eval running across the
  upgrade must be run again.
• HTTP, MCP and CLI use pack lists. POST /projects/{slug}/pack takes
  {"names": [...]} ({"name"} is refused) and answers packs;
  POST /projects takes packs; POST /packs/interview decisions carry
  packs; POST /projects/{slug}/pack/pull requires pack. MCP
  create_project takes packs and get_project and list_projects answer
  packs. CLI: `apptown pack -...

AppTown v1.0.0-rc.11

Flokkit AppTown v1.0.0-rc.11

RC11 repairs container publication, Infrastructure reads and provider confirmation
for Portainer targets,
updates AppTown's Go toolchain to 1.27.3, adds current MCP discovery, and tightens
the resources AppTown's interface loads. It includes all changes since RC9. Take matching database and file backups before
upgrading, as described in the
upgrade guide.

New and improved

• Complete container build inputs. Server and worker container builds copy
  the interface resource policy into the compiler stage. A failed compiler call stops the image
  build immediately. RC10's container publication failed before an installable
  release was produced; these notes cover all changes since the last installable
  release, RC9.
• Inspect and confirm unverified Portainer targets. The target page offers
  inspection of the provider's current identity and asks an administrator to
  confirm that exact observation. Standalone Docker environments reached through
  Portainer's Docker agent are supported. Swarm and other unsupported endpoint
  kinds remain refused. Confirmation records current destination and resource
  associations; it does not establish historical ownership or authorize deletion.
• Infrastructure keeps unavailable observations visible. If a target cannot
  attribute its placements, its recorded deployments remain visible with unknown
  observed state and the reason. Other targets retain their observations. An
  unknown or stale observation is distinguished from a successful empty inventory.
• Current MCP discovery. Clients using MCP 2026-07-28 can discover AppTown
  and make stateless requests with current client metadata. Existing initialized
  sessions retain their ownership checks. Current credentials and permissions are
  checked on each request; successful discovery and legacy initialization retain
  distinct audit records.
• Restricted interface resources. AppTown's interface loads scripts, fonts
  and external stylesheets from its own origin. Its resource policy permits its
  API and terminal connections and the configured browser error-reporting
  destination. Markdown images from external origins become labelled links;
  same-origin images, raster data images and the exact https://apptown.dev
  tour-image origin remain supported. Task-list completion remains visible.
  Hosted applications and previews keep their own policies.
• Go 1.27.3 and library updates. AppTown's server, CLI and worker use Go
  1.27.3. Building AppTown from source requires Go 1.27.3 or newer. Updates
  include age, Sigstore, certificate transparency, container-registry and Docker
  clients, canonical JSON, OAuth and related libraries. Staticcheck and
  golangci-lint are updated for compiler compatibility.
• Dependency maintenance. Security updates bound RSA JWK parsing and fix
  quadratic HTML parsing in deployment checks. Docker runtime/base images and
  the Node build-image digest are updated. Renovate covers coordinated project
  tool pins, stock toolchains and runtime images; a private-Docker proposal still
  requires worker-profile qualification before it can be used.
• Upgrade and interruption regression coverage. The frozen RC9 fixture is
  included for subsequent upgrades. The CLI interruption test waits until its
  child process has recorded a usable process ID before sending a signal.

Declaration changes

No application-contract, workflow, check, scanner or pack declaration fields are
added or removed. Dependency-maintenance annotations and configuration
are updated; existing runtime qualification requirements remain in force.

HTTP API changes

These changes are relative to RC9. The HTTP API remains experimental. The
OpenAPI description
contains the available route definitions.

• GET /oauth/login.js serves the fixed same-origin OAuth login-page script.
  AppTown's interface responses send the resource policy described above.
• /mcp supports the MCP 2026-07-28 stateless discovery/request transport when
  that protocol version is explicit and no session ID is supplied. Requests with
  session IDs retain legacy session ownership checks. Authentication, body limits
  and tool authority are unchanged.
• GET /api/v1/infrastructure returns recorded placements with unknown state
  when an individual target's attribution is unavailable, instead of failing
  the whole read. It retains other targets' observations and reports the reason.
• The existing GET and POST /api/v1/targets/{name}/provider-association
  inspection and confirmation operations support standalone Docker agent
  endpoints. No new confirmation route is added.

Deprecations

None.

AppTown v1.0.0-rc.9

Flokkit AppTown v1.0.0-rc.9

RC9 makes projects easier to create and rename, adds named release environments
and external sign-in, and brings operational warnings together in Attention.
It also tightens checks, credential handling and recovery of retained database
storage. Read the upgrade changes below before updating an RC7 installation.

Upgrade correction

RC8 was withdrawn because its repository-layout migration rejected historical
ended console sessions that legitimately had no checkout path. RC9 preserves
that history while retaining the checks required for live sessions and orphaned
checkouts. The upgrade regression now includes this retained RC7 state.

The changes below cover everything since RC7, the previous available release.
Take matching database and file backups before upgrading, as described in the
upgrade guide.

New and improved

• Start with what you want to build. Project creation starts with a
  description and proposes a name and address you can change. Local repositories
  use immutable project IDs. Renaming a project keeps its previous addresses
  usable and does not rename its upstream repository or running apps. Addresses
  stay reserved even after a project is purged.
• Name your release environments. Targets, integrations and deployments can
  have your own labels. Select a project's default release environment and use
  the same release plan and permission checks as a release to a named deployment.
  Application hostnames belong to deployments, independently of project names.
  Newly prepared Docker apps and previews receive their exact browser origin,
  removing wildcard trust of sibling projects. Portainer connections and upstream repositories are checked against
  their recorded provider identities before use.
• External sign-in. Add one OpenID Connect provider alongside local password
  sign-in. Accounts link through stable provider subjects, not matching email
  addresses. An enabled local administrator remains available for recovery.
  This does not configure sign-in for the apps AppTown hosts. See
  external sign-in.
• Attention. A shared page, top-bar count and Home summary show operational
  warnings for resources you can read: storage, workers, deployments and data
  protection. Missing or stale observations remain visible. Disk warnings are
  bounded on large disks and show their threshold.
• Application health. Portainer honors declared ports, ordered initialization
  and health checks for the exact release. App Platform honors startup grace and
  expected readiness status. Maintained health observations use the declared
  execution policy and distinguish the running generation from a failed update.
• Bounded Janitor assessment. Preview and record standing consent, then
  inspect an exact candidate for supported npm patch/minor updates, same-version
  Node base-image digest updates, supported security fixes and explicitly
  classified guidance-only adoption changes. Unsupported changes require a
  person. Automatic acceptance, landing and deployment are not available.
  Saving consent or running an assessment does not update software. See
  Janitor.
• AppTown update preparation. Administrators can check signed release
  notifications. Linux archives include a separate managed supervisor for
  explicitly enrolled root-run systemd and local Docker installations. It keeps
  installation identity and interrupted-update startup controls outside AppTown's
  replaceable directories. Enrollment does not enable automatic replacement.
  Continue to use the documented
  upgrade procedure.
• A revised tour. The tour follows the current project flow, demonstrates a
  plain club website becoming a bright neon version, and preserves tours at
  versioned URLs so earlier releases remain viewable.
• Stock content ships beside release binaries as update files. Packs can name
  tool lines, and versions record their source and signer. The .NET way of
  working moves to .NET 10; the Go starter trusts configured extra certificate
  authorities. Homebrew support is available for final releases; release
  candidates do not update the formula.

Breaking changes

Upgrades and whole-AppTown restores start at RC7

The oldest supported installation and backup schema is now 167
(1.0.0-rc.7). Earlier schemas are refused before migration or restore
changes data. RC7 and RC8 installations retain their records and versions;
new installations use the complete assembled schema. RC7 archives without
database provenance remain supported. Retired migration history remains
in Git.

Root-installed archive ownership

The Linux installation instructions now keep extracted release files owned by
root, rather than the release builder. Existing archive installations should
stop the service and repair ownership of /opt/apptown (or
/opt/apptown-worker) before restarting; see the
server setup guide.
Do not change ownership of the data directory or project repositories.

Native Mac database storage

Fresh native Mac installations keep the built-in PostgreSQL database in a
Docker-managed volume. Docker Desktop's shared Mac filesystem can otherwise
change observed ownership during initialization and leave startup unable to
complete. Existing bound volumes stay in place; no data moves automatically.
The local pgdata receipt records the managed volume before PostgreSQL starts.
Missing or replaced recorded storage requires recovery. Use a whole-AppTown
backup or a database dump plus the matching data-directory copy; a directory
snapshot alone does not contain a managed database. Linux storage is unchanged.

Local repositories move to immutable project locations

Startup moves existing local repositories to project-ID directories before
application recovery. An interrupted move resumes from its journal. Unknown
ownership or surviving writers stop the upgrade for operator investigation;
AppTown does not guess which files belong to a project. -verify-only performs
this layout transition as well as schema changes. Stop writers and keep matching
database and data-directory backups before upgrading. See the
upgrade guide.

Keep the shipped update files beside the binaries

Copy share/ with bin/ when installing an archive. The daemon and worker now
read the shipped ways of working and tool versions from share/apptown/updates;
they do not start without the required files. Copying only a replacement binary
is no longer sufficient.

Confirm existing Portainer targets and addresses

Before releasing an existing Portainer deployment, an administrator must inspect
and confirm the target's provider association. Then inspect and confirm each
upgraded deployment's observed host rules and certificate domain. The upgrade
keeps the old addresses as evidence but does not treat them as verified.
These confirmations do not change the running stack or clear restore holds.
Old pending release requests without the required address snapshot need a new
release request after confirmation. See
Portainer connection identity
and deployment addresses.

Checks say "not applicable" instead of passing on nothing

A check that had nothing to judge used to pass: a Go check with no go.mod,
a frontend check with no frontend, an image scan with no image. Now each
check says what it applies to, and AppTown works out from the app contract
whether it applies before anything runs. A check that does not apply says
not applicable and why ("no part is built with go"). It is never a
pass and never an error. It does not stop anyone approving or landing, and
the change's record lists every check that was not applicable, so none is
read as passed. Once a check applies, finding nothing to judge is a
failure: the contract and the code disagree.

What changes for an existing project:

• Landing is stricter.
  • The tests step fails when a part is built with Go, Node, Python,
    Ruby, Java, .NET or Rust and no test command is found. Before, it
    passed with "no tests found". A test command AppTown already found
    still runs, whatever the contract says.
  • The dependency scan (osv) fails when it finds no package files in an
    app whose parts are built with a language it reads. Before, it passed.
    A .NET app now commits packages.lock.json.
  • An app whose public part is a static site has image scans that say not
    applicable. Before, they passed with a note.
• The shipped checks' scripts fail where they used to pass on a missing
  subject, once the check applies.
• The app contract gains two fields, both optional:
  • tools: on a part names what it is built with, for example
    tools: [go, node]. Without it, a project's language checks, the
    dependency scan and the licence scan are not applicable.
  • notAppCode: lists folders whose code is not the app's (docs, tooling).
• A new platform check, "the contract matches the code", reports each
  package.json, go.mod, pyproject.toml, Gemfile, Cargo.toml, pom.xml,
  .csproj, composer.json or project.godot that no part's tools: covers.
  It fails a landing that leaves a new one undescribed.
• The check format gains appliesTo, and it is required. A check, or a
  scanner that is not manual, saved without it is refused. Checks and
  scann...

AppTown v1.0.0-rc.7

Flokkit AppTown v1.0.0-rc.7

The seventh candidate for 1.0. It replaces RC6 as the candidate running in
production with the maintainers, and the two-week run before 1.0 starts on
it, on 24 October 2026.

RC6 was never run for its two weeks. The maintainers' production AppTown
left RC6 on its first day, 23 October, and ran builds of main until this
candidate. So RC7 is also the first candidate to run in production with
RC6's own changes, including its fixes.

RC7 gives the certificates of a company's TLS-inspecting proxy to every
container and build AppTown starts. It backs up and restores a whole
AppTown with one command each way. It removes the move from the names
things had before 1.0, which RC6 added. It fixes two defects that showed
up as intermittent test failures, clears the open dependency advisories,
and makes the shipped guides' links work on GitHub.

In short

• Behind a company's TLS-inspecting proxy, everything AppTown starts
  trusts the company's certificate authority. Agent, script, test and
  check steps, chats, screenshots, scanners, image builds, previews and
  deployed apps get the certificates given with -trust-deployments. RC6
  covered only AppTown's own connections.
• apptownd backup and apptownd restore back up and restore a whole
  AppTown. The archive is always encrypted with a passphrase. After a
  restore, AppTown checks App Platform and Portainer deployments against
  what their providers run and takes them over again.
• apptown move-names and its route are removed. They came in RC6.
  Every deployment must be named by its key before upgrading; migration 167
  stops the upgrade otherwise and names each one.
• Fixes: a landing's deploy is no longer cut short when its run is
  abandoned, and a cancelled database statement now fails as cancelled
  instead of as a network timeout.
• Dependencies: the open Go and npm advisories are fixed, and CI fails
  on a new high or critical npm advisory.
• The WordPress starter's theme is apptown-site for new projects.
• The tour on apptown.dev is made by the release itself, from the
  tagged source.
• RC7 has two database migrations, 166 and 167.

What changed

Extra certificate authorities in containers and builds

RC6 let AppTown's own connections trust extra certificate authorities, with
-trust-inference, -trust-deployments and -trust-apptown. The
containers AppTown started did not trust them, so a step that downloaded a
package behind a TLS-inspecting proxy failed. Now the -trust-deployments
certificates go to everything AppTown starts. With -local-tls, AppTown's
own local authority goes too, but only to containers on that machine.

• One script, APPTOWN_TRUST, adds the certificates beside the image's
  own roots, never in place of them. It sets the variables programs read
  (SSL_CERT_FILE, NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE and
  others), apt's setting, the JVM's trust store (through
  JAVA_TOOL_OPTIONS), Chromium's store, and, as root outside a build, the
  system store. With no certificates set, it does nothing.
• Agent, script, tests and check steps, chats and screenshots run it
  before their command, and again after installing the project's declared
  toolchain, so a JVM that mise installs trusts the certificates too.
  Scanners that use the network run it first.
• The private Docker daemons of steps, chats and release builds, and
  the builder inside them, trust the certificates for their own pulls.
• Every image AppTown builds (previews, releases, check images and the
  agent image, including a worker's at its first start) gets the
  certificates as the build secret apptown-trust. The twelve starter
  Dockerfiles mount it in each RUN that downloads. Building with the
  secret needs buildx (Docker 23 or later).
• Deployed apps and previews on Docker hosts, Portainer and App
  Platform get the variable APPTOWN_TRUST, and the starters' start
  commands run it. Attached hosts, Portainer and App Platform never get the
  local authority. A command: in .apptown/app.yaml replaces the image's
  CMD, so it must run eval "${APPTOWN_TRUST:-}" itself if the app calls
  out.
• An image with no shell cannot run the script and keeps only its own
  roots. The go-small starter's distroless runtime is one.
• The build/container-image guidance says how a Dockerfile uses the
  secret and the variable. Projects started before RC7 keep their
  Dockerfiles, so they add the lines themselves.
• Every apptown-worker flag can also be set by its APPTOWN_ variable,
  as apptownd's already could.

Setting up a server
and the app contract
describe it.

Backing up and restoring a whole AppTown

• apptownd backup [-store] <archive> asks the running AppTown for one
  archive. First it backs up each app on AppTown's own Docker host, one at
  a time, with that app's parts stopped and then started again. Then it
  holds new jobs and steps for a moment, dumps the built-in database and
  copies the data directory (without pgdata and cache). -store also
  copies the archive to the backup store that deployment backups use.
• The archive is always encrypted with a passphrase (age). It holds
  every secret AppTown has. The passphrase is asked on the terminal, or
  read from the file APPTOWN_BACKUP_PASSPHRASE_FILE names. Without it the
  archive cannot be opened. An external secret store such as Infisical
  keeps its own values, and the archive's manifest says so.
• apptownd restore <archive> runs on a host with no AppTown. It
  refuses a host that already has an AppTown's database or deployment
  containers, or a data directory that is not empty. It checks the files
  and the dump against the manifest, loads the dump, compares each table's
  rows with it, and opens the database as -verify-only does.
• Apps on AppTown's own Docker host are rebuilt from their last release
  at the first start after a restore, with their data put back before any
  part of the app runs. If a copy is missing or partial, nothing starts and
  the deployment's card says so.
• App Platform and Portainer deployments are checked against their
  providers every minute after a restore. If the provider runs the
  recorded release, AppTown carries on. If it runs a different one,
  AppTown records it as a release "observed after restore", which AppTown
  did not ship. The release AppTown last shipped there can still be
  deployed again. If the app is gone, a person decides. If the provider
  cannot be read, AppTown asks again. Until a deployment is checked,
  AppTown does not release to it, restore into it or take it down,
  including work queued before the backup.
• scripts/apptown-recovery-rehearsal.sh now uses the two commands.

AppTown's own backups
leads with them.

Fixes

• A landing's deploy runs to its end when its run is abandoned. Before,
  stopping the run could cut the deploy short. AppTown then recorded its
  outcome as uncertain, and main refused every release until a recovery
  check decided it, usually as failed. A start stopped part way could leave
  main between two versions. What comes before the deploy starts still
  stops.
• A cancelled database statement fails as cancelled. When a
  cancellation cut short a statement while it was being sent, the error
  was a network timeout (write tcp ...: i/o timeout), which no caller
  could tell from a real network fault. The error is now both the
  cancellation and the timeout, over plain and TLS connections.
• The repo/no-build-artifacts check says "could not assess" when it
  cannot list or read a project's files, instead of passing.
• RC6's fix for a step that finished just as its run ended (it was treated
  as lost and cancelled) is in production for the first time, because RC6
  never ran there.

Dependencies

• Go: klauspost/compress 1.18.7 and grpc 1.83.2.
• The web interface: vite 6.4.4, vitest 4.1.12, react-router-dom 7.18.2,
  mermaid 12.2.0 (with katex 0.18.2), dompurify 3.4.17, js-yaml 5.4.1,
  undici 8.10.2, brace-expansion 5.0.12 and source-map-js 1.2.2. Each is
  the smallest version that fixes its advisory.
• The frontend-only and video-game starters, which new projects of
  those kinds start from, take vite 8.3.3 and 6.4.4 respectively, and
  source-map-js 1.2.2. Existing projects keep their own lockfiles.
• A new check, make check-npm-audit, runs in CI. It fails on a high or
  critical advisory in what the web interface ships, or in any starter's
  lockfile, unless scripts/npm-audit-exceptions.txt lists it with a date
  and a reason. It fails too when npm cannot get the report.

Starters and guides

• The WordPress starter's theme is apptown-site, with an apptown/
  Composer package name and an apptown- S3 plugin name. Projects started
  earlier keep the theme and files they were given, and the guidance says
  so.
• The shipped guides' links work on GitHub and on the Docs page. A
  guide links another by its file (split-install.md), which GitHub
  follows and the Docs page turns into its own route. make check-docs
  checks every link in the guides and the release notes, and now runs in
  CI.

Releases and CI

• The release workflow makes the tour on apptown.dev from the tag's
  source, and publishes the site with it. The screenshots are no longer
  kept in the repository. A test tag (-test.N) makes the tour and leaves
  the site alone.
• A release's images and archives are built only when heavy.yml passed
  on the commit at its first attempt. A run that passed only when re-run
  does not count. heavy.yml now also runs on every p...

AppTown v1.0.0-rc.6

Flokkit AppTown v1.0.0-rc.6

The sixth candidate for 1.0, and the first under the product's new name,
Flokkit AppTown (AppTown for short; it was Flokkit, and the code called it
"forge"). It replaces RC5 as the candidate running in production with the
maintainers, and the two-week run before 1.0 starts again on it.

RC6 renames everything people, agents and apps see from "forge" to
"AppTown", and fixes the app contract that 1.x keeps stable (version 2). It
makes each stock need give an app the same values on every deployment
target. It backs up object storage and Portainer deployments, and gives
every deployment its own database and storage credentials. It adds a
one-command desktop trial over HTTPS. It closes what 1.x could not change
later, removes features nobody used, and fixes defects found in the RC5 run
and in a first desktop trial.

Since 22 October 2026 the code changes on GitHub, at
github.com/flokkit/apptown, one pull request per change.

In short

• The product is AppTown, and so are its names. The commands are
  apptown, apptownd and apptown-worker. Settings are APPTOWN_*,
  headers X-AppTown-*, and tokens start apptown_. The repository folder
  is .apptown/. AppTown reads none of the old FORGE_* names.
• Apps get only the new names: APPTOWN_ORIGINS, APPTOWN_RELEASE,
  APPTOWN_BROWSER_ENV*, window.__APPTOWN_ENV__ and /_apptown/, and no
  FORGE_*.
• The app contract is version 2: memory in Mi/Gi, cpu in cores or
  millicores, and ${needs.<need>.<VARIABLE>} to pass a need's value under
  another name. It refuses values, names and fields that 1.x could not give
  a meaning later, and says what to write instead.
• Every stock need gives an app the same connection values on every
  target, as contract-reference.md sets out. Each deployment has its own
  database and storage passwords.
• Backups now cover object storage and Portainer deployments, and were
  proven on a real Docker host, App Platform and Portainer. Restore
  rehearsals run on the app's own host when no host is kept for them.
• What AppTown makes for a deployment is named by the deployment's id,
  under apptown-, with apptown.* Docker labels.
• Sign-in is the default. apptownd starts with -auth internal unless
  told -auth open.
• Settings an administrator changes are set in AppTown, not in flags.
  Five apptownd flags are gone, and the flags that remain are promised
  for 1.x.
• Features nobody used are removed: the backlog, project export, the
  check-only worker, webhook triggers and others (see "Removed").
• Try it with one command on your own computer, over HTTPS. It installs RC6.
• Behind a company's TLS-inspecting proxy, AppTown's own connections can
  trust that company's certificate authority. The containers AppTown starts
  do not trust it yet. That comes in RC7.
• No automatic upgrade from a release candidate. RC6 is for new
  installs. See "Upgrading from RC5". It has thirteen database migrations
  (153 to 165).

What changed

The new name

• The product is called Flokkit AppTown, AppTown for short. The web
  interface, the server's and the CLI's messages, the guides, the README,
  NOTICE and the GitHub repository (flokkit/apptown) use it. The Go
  module is github.com/flokkit/apptown. The container images are
  ghcr.io/flokkit/apptown, apptown-worker and apptown-agent.
• Commands, install paths and settings. The daemon is apptownd, the
  CLI apptown, the worker apptown-worker, and the restore gate
  apptown-gate. A server install uses /opt/apptown,
  /etc/apptown/apptownd.env, /var/lib/apptown and apptownd.service (a
  worker: /opt/apptown-worker, /etc/apptown-worker,
  apptown-worker.service). Every daemon flag is set as APPTOWN_<FLAG>.
  FORGE_ variables are not read. The operator secrets are
  APPTOWN_WEBHOOK_TOKEN and APPTOWN_APPS_DOMAIN. The agent image's
  default tag is apptown-agent.
• The built-in database of a new install is the container apptown-db
  on the volume apptown-data-apptown-db, and the database inside is
  apptown. db.env records these names, so an install made before 1.0
  keeps its own. The trial keeps its data in /var/lib/apptown/data. The
  SSH host alias for an attached Docker host is apptown-target-<name>.
• The CLI and agents. The CLI reads APPTOWN_URL, APPTOWN_TOKEN,
  APPTOWN_USER and the rest, and its credentials from
  ~/.config/apptown/credentials. Agent steps and chats get APPTOWN_*
  variables and see AppTown's inputs at /apptown/in and /apptown/state.
  The MCP server is named apptown and its scopes are apptown:*.
• What leaves AppTown. Request and response headers are X-AppTown-*
  (and AppTown-Restore-Token, AppTown-Gate, AppTown-Head); new commits
  carry AppTown-* trailers (commits already written keep Forge-*); new
  tokens start apptown_ (apptown_invite_, apptown_mcp_, apptown_git_
  and so on); the session cookie is apptown_session; metrics are
  apptown_*; the OpenVEX document names apptown:project/<slug>. AppTown
  names itself apptown to outside systems it sets up from now on (a
  registry login, a Git remote user, a GlitchTip team). Outside objects that
  already exist keep their names.
• AppTown's own acts read as AppTown. The audit log, a target's History
  and the Usage page show AppTown's own actions as "AppTown"; the stored
  records are not rewritten.
• The guides were renamed and checked. running-a-forge and
  what-forge-is-for are running-apptown and what-apptown-is-for. Every
  shipped guide was checked against the code and rewritten where it was wrong
  or out of date (for example, apptown dev writes .apptown/dev.env and
  .apptown/Procfile, and a preview stops eight hours after it was last
  looked at). The roadmap guide is folded into "What 1.0 promises", under
  "Not in 1.0".
• The guidance, workflows and packs agents read say AppTown, and
  messages no longer cite design-document paths.

Names AppTown gives what it makes

• Named by the deployment's id. Two deployments could share a
  container, a network and a database volume on a Docker host: project
  shop with deployment eu-main and project shop-eu with deployment
  main made the same name. Everything AppTown makes for a deployment is
  now named from its key, the last 12 hex digits of its id:
  apptown-dep-<key> for the app, apptown-svc-dep-<key>-<name> for its
  services, apptown-need-dep-<key>-<need> for a need's data, and so on.
  Portainer stacks, App Platform apps, database clusters, Spaces keys and
  buckets are named the same way.
• Docker labels are apptown.*. A deployment's containers, network and
  volumes also carry apptown.project and apptown.deployment.name, so a
  person can tell from docker ps whose they are. AppTown never reads
  those two.
• Moving an older deployment. A deployment made before this keeps
  working under its old names. apptown move-names <project> <deployment>
  moves it. AppTown releases what it runs again and stops it. It copies
  each data volume to the new name and checks every file, owner, mode and
  link of the copy. Then it switches the record and starts the app under
  the new names. The old volumes stay on the host until someone deletes
  them. A copy that does not check out puts the old app back. Portainer
  deployments are not moved: take one down and release it again.
• Leftovers from older releases. At start, AppTown and each worker
  remove the throwaway containers an older release left with forge.*
  labels (previews, step and chat containers, checks, tasks). A chat or
  preview open at that moment is made again when next used. A deployment's
  own containers and volumes, and the built-in database, are not touched.
• Throwaway containers take their anonymous volumes with them. Checks,
  tests, tasks, agent steps, a step's services and copy jobs were removed
  without their anonymous volumes. A busy host gained hundreds to thousands
  of unused volumes a day. These are now removed with -v. Named volumes,
  which hold data, are never touched. Standing deployments are still removed
  without -v, and AppTown does not run docker volume prune. Volumes
  already left on a host stay until someone removes them.
• These names are not promised. "What 1.0 promises" says how AppTown
  names and labels what it makes may change in 1.x. Names already given
  stay.

The app contract

• Fields that do nothing are refused, by name. A version-2
  .apptown/app.yaml is refused if it uses seed; healthcheck on the
  public part; the health period, timeout, thresholds or checksDeps; a
  tcp or exec readiness probe; dataDir on a part that is not public; or
  sets PORT, APPTOWN_ORIGINS, DATA_DIR or APPTOWN_RELEASE in an
  environment. Each refusal says what to do instead. These were accepted
  and ignored, or behaved differently by target; refusing them now lets a
  later release give them a meaning without changing what existing apps do.

• What a 1.x release may still change is listed in the compatibility
  guide: the limits it names (health timings and probe kinds, Portainer init
  ordering, where integration values arrive, seed, origins and dataDir
  delivery) may be lifted; nothing else in the contract changes meaning.

• APPTOWN_ORIGINS and command are written down: the origins format,
  and that a string command runs with sh -c.

• One exact app contract. contract-reference.md says what an app must
  do and what AppTown gives it: the files read, what a build sees, the
  process, the environment by target and part, startup order, what arrives
  through the front door, health and static sites. Where targets still differ
  (health checks, startup order on Portainer), it says how. "What 1.0
  promises" names it ...