Skip to content
Artbucket

Upgrading

Start the new version. Before it serves anything, it applies every database migration it has that the database doesn’t, in order, in one transaction. If one fails, the server stops rather than run on the wrong schema, and the database is as it was.

Terminal window
# Docker Compose
docker compose --profile app pull && docker compose --profile app up -d
# Docker
docker pull ghcr.io/pwnera/artbucket:1 && docker rm -f artbucket && docker run ... ghcr.io/pwnera/artbucket:1
# Kubernetes: newTag in kustomization.yaml, then
kubectl apply -k deploy/kubernetes/app

On Render, Manual Deploy, Deploy latest reference pulls the newest image of its line.

What makes that hold

Section titled “What makes that hold”
  • Migrations are only ever added. A released one is never edited, and CI fails a pull request that changes one.
  • CI fails when the schema has a change no migration makes.
  • CI migrates a database at the previous version, filled with a library in use, to the new one, on every pull request.
  • Several instances starting at once take turns: the first migrates, the others find nothing left to do.

Take a backup before a major upgrade anyway: pg_dump for the database, and your bucket’s assets/ prefix for the originals.

Which tag to run

Section titled “Which tag to run”

ghcr.io/pwnera/artbucket:1 follows every 1.x release: fixes and additions, never a change that breaks an integration (Stability). Pin a minor line (such as 1.8) to take fixes only, or a version (such as 1.8.1) to move only when you say. Not every release has an image: the registry lists the tags there are, and the releases what each changed.

Before 1.0 the API changed between minor versions (0.8 to 0.9); the release notes said how. From 0.9, upgrading to 1.0 changes nothing you call.

Notes by version

Section titled “Notes by version”

2.2. The guidelines builder is gone, and BUILDER is no longer read. Rules are edited on a brand’s Rules tab, the look on Theme, and Edit opens the ways to change the pages (an agent, Git, Eject to code). Links to /brands/{slug}/guidelines/edit redirect to where that work is now.

1.11. Set TRUSTED_PROXIES (private behind one reverse proxy): the server no longer believes X-Forwarded-For unless it names the proxies. Until set, every client shares one rate limit. See Security. Agents connected over OAuth (and artbucket login) now hold tokens that last an hour and renew themselves; those connected before keep working for 30 days, then connect again. Keys an admin makes are unchanged.

1.8. Sign in with Google, and Google or OIDC sign-in at an organization’s own domain. Any verified domain may serve the app, each turned on in Settings, Domains. Who sees an asset is said plainly and chosen at upload. An MCP tool now refuses an argument it doesn’t take: send only what the tool lists. A CLI push keeps what changed in the app.

1.7. The first release of the roadmap’s Analytics milestone, on top of 1.6.1.

1.6. Brand pages and the builder, brand as code (the brand as YAML in a Git repository), releases as pages, BrandHub and Insights. 1.6.1 adds joining an organization by its email domain, and requiring single sign-on for a domain (0015).

1.5. Nothing to do. A pass over the whole app’s feel. Brand guidelines are edited in place, as in Notion: no Edit mode, “/” to add a rule or a block, a handle to move one, autosave with Saved or Not saved in the header, and Undo after a delete. The sidebar stays mounted between pages, and every page shares one header. Motion, focus, pending buttons, copy, confirm and undo work the same way everywhere. /api/v1 and the MCP tools are unchanged.

1.4. Asset files are private. /a/{id} now serves people who can see the asset, and anyone with a signed URL; to keep an embed made before 1.4 working, make its asset public (Share, Public, or PATCH /api/v1/assets/{id} with public: true). Share links and portals keep working: they sign what they show. A domain is verified by its TXT record and, with DOMAIN_TARGET set, its CNAME; an organization can have several, one the default, and a portal picks one of them instead of claiming its own. Agents can suggest custom field values (propose_fields), as they suggest tags. /api/v1 and the MCP tools only gained things. Why: 0012.

1.3. Nothing to do. With EMAIL_* set, organizations’ own email settings are no longer used or offered, and accounts that never confirmed their address get a code at their next sign-in. Portals can publish brands.

1.2. Nothing to do. The app icon is now served at /icon.svg; page titles follow each organization’s brand.

1.1. Nothing to do. Portals on their own domains need the proxy in front to issue certificates for them: see Portals.

1.0. Nothing to do. /api/v1 and the MCP tools are frozen from here.

0.9. Deleting an asset now keeps it restorable for 30 days. Browser uploads started before the upgrade and finished after it need to be started again.