Self-hosting Cobblr

Run Cobblr on your own machine, on your own network, with nothing but Docker. No subscription, and nothing you have to sign up for to use it. What you run is the full thing, and this section gets you to a working instance you can open from your phone, camera included.

The loop:

1. Check what you need: a box with Docker, and its LAN IP.
2. Pick how you get HTTPS for the camera. Tailscale is the recommended answer.
3. Install: two files and docker compose up.
4. Put your email in SUPERADMIN_EMAILS so you are the operator.
5. Operating covers updates and backups from there.

What you need

• A machine on your LAN with Docker and Docker Compose. Linux, a Mac, a NAS, a mini PC, a Raspberry Pi (4/5, 64-bit), or an old laptop all work.
• The box's LAN IP (for example 192.168.1.50). Give it a DHCP reservation so it doesn't change out from under you.
• No repo to clone and nothing to compile. Install is two files and docker compose up.
• No email server. Sending email is optional. With nothing configured, password login works as normal and invites become copy-the-link.

How much machine

• For yourself or a household, a Raspberry Pi 4 or 5 with 4GB or more is plenty. Put Postgres on a USB SSD, not a microSD card (a cheap SATA SSD in a USB 3.0 UASP adapter is a good example).
• For a busy instance with many active workspaces and users, a small x86 box has more headroom for less money: a used mini PC (an Intel NUC, a Beelink) or a refurbished small-form-factor desktop with 8 to 16GB and an SSD is the sweet spot.

Why the hardware bar is low

At runtime Cobblr is light: a Node API, Postgres, and a proxy, with no local AI compute (AI and embeddings run on the provider you connect, not the box). The images are prebuilt (multi-arch, so a Pi pulls the arm64 build), so there's no on-device compile: the first run just pulls and starts. A microSD card is slow and wears out.

The one gotcha: HTTPS for the camera

To scan from your phone you need HTTPS. A plain http://192.168.x.x LAN address is not a secure context, so the camera is silently blocked. We recommend Tailscale.

Option	Nothing exposed to the internet	Trusted certificate	Per-device setup
Tailscale (recommended)	yes	yes, automatic	install the app once
Offline CA (tls internal)	yes	self-signed, trust it once	install a certificate
Cloudflare	no, you forward a port	yes	none

• Tailscale gives Cobblr a real, auto-renewed ts.net certificate, handles the name and the routing itself, and forwards nothing to the internet. In the easiest setup the bundled proxy joins your tailnet on its own, so the box needs no Tailscale install. Install the app on each phone or laptop you browse from, sign them into the same tailnet, and approve the box once from a one-time link the proxy prints (or hand it a reusable auth key for a fully headless join). The same URL then works at home or across the country, with no certificate to install by hand, and it doubles as secure remote access.
• Cloudflare is the internet-facing path: it points a name you own at your box so anyone can reach it, which means forwarding a port, so you disable signup and rely on login.
• Offline CA is the no-network, no-Tailscale fallback: it works fully local but you trust its certificate on each device by hand.

Install offers both speeds: a five-minute HTTP fast path you upgrade in place, or Tailscale from the start.

Why HTTPS is the real constraint, and why Tailscale wins

Browsers only let a web app use the camera (barcode scanning, photos) in a secure context, which means HTTPS or localhost. No app-side flag changes this. It's a browser rule. A home box makes HTTPS awkward: a public certificate authority will not issue a certificate for a private IP, and a public name can't reach your box unless you either open a port to the internet or run your own local DNS. That is the real constraint, and it's why the options above trade off differently.

Tailscale sidesteps the whole problem in one move. For a tool you reach from your own devices, that is the entire HTTPS story, and nothing else here is both private and this simple. The others exist for cases Tailscale doesn't fit.

You are the operator

• Grant yourself the role by putting your email in SUPERADMIN_EMAILS in .env, then registering your account normally. Nobody gets there by signing up. It is your email on the box that unlocks it.
• The operator console is at /admin. See and manage every workspace and every user on the instance: check its health, adjust instance-wide settings, mint sign-up invites, and remove a workspace outright.
• View-as mode shows a workspace as one of its users sees it, read-only unless you flip the write toggle, with a loud banner while you're in it.
• A product-metrics dashboard covers the whole instance.

How the operator tier relates to workspace roles

Running the instance makes you its operator, a super-admin who sits above every workspace. This tier is about running the server, so it's separate from the per-workspace roles (owner, admin, and the rest), which keep working exactly as they do inside each workspace.

A real, multi-tenant instance

Self-hosting doesn't mean a stripped-down single-user build. What you run is a production-level, multi-tenant server.

• One box can host many user accounts, each with their own isolated workspaces, and every workspace keeps its own database.
• Run it just for yourself, or open it up to a household, a makerspace, or a business, all doing their own thing, every space walled off from the others.