Run Upliftr locally

Upliftr is AI debugging agents that debug your app across your flow and your servers, read-only by design. Two commands and you're running them at https://upliftr.test, real HTTPS, green padlock, no warnings.

1. Install

curl -fsSL https://get.upliftr.io | bash

It pulls the prebuilt images (no build), generates an admin, and starts everything behind a local HTTPS proxy. It asks for sudo to (a) map upliftr.test to your machine and (b) trust the local certificate authority so the cert is valid in your browser.

2. Open it

https://upliftr.test

Log in with the admin email + password the installer printed (also saved in ~/upliftr/.env). Add your Anthropic key in Settings → AI, and you're ready.

That's it.

Why a local CA?

upliftr.test isn't a public domain, so it can't get a normal (Let's Encrypt) certificate. Instead the installer runs a local certificate authority and trusts it on your machine, that's what makes https://upliftr.test green. Chrome, Safari, and Edge are covered automatically; Firefox keeps its own trust store, so it may need the CA added once (the installer attempts it if certutil is present).

---

Upgrading

Just re-run the one-liner, it's also the upgrade path:

curl -fsSL https://get.upliftr.io | bash

It reuses your existing config (~/upliftr/.env), pulls the latest images, and recreates the containers. Your data is preserved, the database lives in a Docker volume that an upgrade never touches. (It also skips the cert-trust prompt when it's already trusted.)

Managing it

From ~/upliftr:

docker compose -f docker-compose.yml -f docker-compose.https.yml logs -f api   # logs
docker compose -f docker-compose.yml -f docker-compose.https.yml down          # stop (keeps data)
docker compose -f docker-compose.yml -f docker-compose.https.yml down -v       # stop + DELETE data

(Use docker-compose.http.yml instead of …https.yml if the installer fell back to plain http.)

Testing an app running on your own machine

The browser the Upliftr agents drive runs inside Docker, but it's wired to reach apps on your machine automatically. The agents read your flow and your servers read-only, so pointing them at a local app never mutates it. Point the agents at any of these as-is and they just work:

• http://localhost:3000 (and 127.0.0.1), your dev server
• https://gdk.test, https://myapp.test, any .test or .localhost domain (the reserved local TLDs). The real hostname is preserved, so a host that serves several sites by name (Caddy/nginx vhosts, GDK, Valet, …) still routes correctly.

Everything else (a staging URL, a public site) you paste as-is too.

Custom local domains that aren't .test/.localhost (e.g. app.dev, *.local), list them so the container routes them to your machine:

# in ~/upliftr/.env
UPLIFTR_RUN_LOCAL_DOMAINS=*.dev,app.local

Then re-run the installer (or docker compose up -d) to apply.

How it works

The container redirects DNS for these names to the Docker host at the resolver level, it changes where the name points, not the name itself, so the Host header (and your vhost routing) is untouched. Self-signed / local-CA certs are accepted by default. On Docker Desktop (macOS/Windows) this reaches services bound to your machine's localhost. On Linux, bind your dev server to 0.0.0.0 (not 127.0.0.1) so the container can reach it. To turn the whole behaviour off, set UPLIFTR_RUN_LOCAL_ROUTING=false.

Requirements

• Docker Desktop (macOS/Windows) or Docker Engine + Compose v2 (Linux), running.
• Works on Intel and Apple Silicon.

Deploying on a server instead?

Pass a real domain and point its DNS at the host, the installer uses it instead of upliftr.test:

UPLIFTR_DOMAIN=upliftr.acme.com curl -fsSL https://get.upliftr.io | bash

For a full production setup (TLS, backups, teams), see Self-hosting.