The short answer: a self-hosted Artbucket is one container, Postgres 16 or later, and any S3-compatible bucket. Docker alone gets you a working install on one machine. What you take on is what a host would otherwise do: backups, updates, and Office previews if you want them.
How we made this: from Artbucket's installation and configuration docs, read on 6 October 2026. We quote the docs' own sizes and commands; we did not time an install for this post, and we don't quote server prices, which change. Artbucket is our product, and its core is open source (AGPL-3.0).
Why self-host at all
Three reasons come up most. Your files and your brand stay on servers you choose, in the country you choose. Nothing is counted: on your own install there is no limit on editors, viewers or brands. And the code is the same code that runs Artbucket Cloud, so you can read what it does with your data, change it, or leave with it.
The reason not to: someone on your team has to own it. If nobody wants to think about backups, a hosted plan is the better deal.
What you need
| Part | What the docs ask for |
|---|---|
| The app | The image ghcr.io/pwnera/artbucket, for amd64 and arm64, tagged by version |
| Database | Postgres 16 or later. Search is Postgres full-text search: no search cluster, no Redis, no job queue |
| Files | Any S3-compatible bucket: AWS S3, Cloudflare R2, Backblaze B2, Tigris, MinIO, Garage or SeaweedFS (the one bundled with Docker Compose) |
| Memory | The Kubernetes manifests request half a CPU and 1 GiB, and allow up to 4 GiB, since uploads of up to 512 MB are buffered while previews are made. The Render blueprint uses a 2 GB instance |
| Optional | ffmpeg for video thumbnails (in the image); LibreOffice for Word, PowerPoint and Excel previews (not in the image) |
The quickest install: Docker on one machine
"You need Docker. That is all," says the quickstart. Make a secret, then start the bundled Compose file with the app profile:
git clone https://github.com/pwnera/artbucket.git
cd artbucket
export BETTER_AUTH_SECRET=$(openssl rand -base64 32)
docker compose --profile app up -d
That starts Postgres, SeaweedFS for files, and the app. The first account you create is the admin of everything. The database migrates itself on start, and the bucket, its CORS rule and its cleanup rules are made on start too.
Other ways to run it
The docs cover Render (one click, from a blueprint), Docker Compose, plain Docker, Fly, Kubernetes (Kustomize, no Helm chart), Coolify and a plain VPS. Pick the one your team already runs things on.
The settings that matter
Five are required, and a sixth is required in production:
DATABASE_URL=postgres://...
S3_ENDPOINT=https://...
S3_BUCKET=artbucket
S3_ACCESS_KEY_ID=...
S3_SECRET_ACCESS_KEY=...
BETTER_AUTH_SECRET=... # required in production
APP_URL=https://brand.example.com # defaults to http://localhost:3000
One rule from the storage docs is worth knowing before you start: one bucket per database. Two installs sharing a bucket will each clean up files the other one holds.
What you get on your own server
- Everything the core has: the library with renditions as URLs, brand rules as data and the guideline pages drawn from them, releases, portals on your own domains, review, the use check, the REST API, the MCP server for agents and the CLI.
- SSO without a plan: OpenID Connect, server-wide or per organization with domain proof and an option to require it. SAML and SCIM are not built yet.
- No telemetry: the core sends nothing anywhere, not to us and not to anyone.
What becomes your job
- Backups. Back up Postgres and two prefixes of the bucket,
assets/andpreviews/. A built-in backup and restore is on the roadmap, not scheduled. - Updates. Pull a new image tag; the database migrates on start, under a lock.
- Office previews. Install LibreOffice next to the app if you want them.
- Scaling past one process. Rate limits are kept per process; sharing them between several would need Redis, which Artbucket deliberately doesn't use.
- Git integration. The GitHub App that syncs a brand folder and comments on pull requests is Artbucket Cloud's. On your own server you sync with the CLI, a CI job, or your own integration against the documented Sync API.
Limits to know before you commit
Uploads are capped at 512 MB per file. Video gets a one-frame thumbnail, not renditions or transcodes. After Effects and Premiere projects can't be previewed. There are no importers from other DAMs yet: you bring files in with the CLI (artbucket ingest), the API, or by URL. If any of these is a deal breaker, it is better to know now.
Questions
Is the self-hosted version limited compared to Cloud?
No feature of the core is held back. Cloud adds hosting, the GitHub App, portals at *.artbucket.page and BrandHub at hub.artbucket.io. A self-hosted install can run its own BrandHub by setting HUB_URL.
Can we move from self-hosted to Cloud later, or back?
The brand moves as files (artbucket brand pull --assets, then push), and assets through the API and CLI. There is no one-click organization export yet.
What does the license mean for us?
AGPL-3.0: run it, change it, use it commercially. If you change the code and offer it to others over a network, you publish your changes. A commercial license is available for teams that can't ship AGPL.
Related: the open-source DAMs worth a look, and Artbucket's deployment options.