Arcturus — your team's own little cloud

01

Everything a small team actually needs

and nothing it doesn’t

01

🚀 Static sites in seconds

Served straight from disk, live the moment the upload finishes. Even a single .html file works; it becomes the index automatically.

02

🐳 Dockerfile apps

If there’s a Dockerfile in the zip, the image is built and run as a container, routed automatically, with a dedicated port included.

03

⏮️ Rollback in one click

Every app keeps its last 5 releases. Jump back to one from the dashboard or with arcturus rollback.

04

🔐 Env vars, encrypted

Per-app environment variables, stored AES-256-GCM encrypted in SQLite. Saving them recreates the container right away — no rebuild.

05

🛡️ Safe by default

Apps run on a separate origin, so one can’t ride your dashboard session. Containers are locked down, logins are rate-limited, and logout kills the session on the server.

06

♻️ No downtime on redeploy

The dashboard and API swap blue-green behind an ingress, so :7777 and :7778 keep answering while you ship.

07

👥 Made for a team

The admin hands out invite links; everyone manages their own apps. Share an app as view or manage — and a manage teammate can deploy to it too.

08

🌐 Korean & English

The dashboard, API messages, and the CLI all speak both, following the browser or the ARCTURUS_LANG setting.

02

How routing works

the hard part, handled

Path-prefix proxying (/alice/blog) breaks apps that reference assets by absolute path. Arcturus layers three remedies, so things just work:

1

Prefix strip + `X-Forwarded-Prefix`

Apps with a configurable base path work as-is — the gateway strips the prefix and tells the app where it lives.

2

Referer fallback

Unmatched requests like /static/app.js are re-routed to the app the browser is currently viewing.

3

Dedicated port

Every container app keeps a fixed port (30000+) with zero base-path issues. New container apps default to “redirect” — visitors are bounced straight to it. The port is auto-assigned, or pick your own from Port settings.

03

The CLI

one binary, no runtime

The gateway serves the installer and platform binaries itself — your server is the distribution channel:

$ curl -fsSL http://<host>:7777/install.sh | sh

Command	What it does
arcturus login --server … --token …	Authenticate (token from Dashboard → API Tokens)
arcturus deploy	Zip the current directory and deploy (Dockerfile → container)
arcturus apps	List your apps
arcturus deployments <app>	History, with live / rollbackable markers
arcturus rollback <app> <id>	Restore a previous release
arcturus env <app> --set K=V	Env vars — recreates the container, no rebuild
arcturus logs <app>	Follow container logs
arcturus destroy <app>	Delete the app

Pin an app name per project with arcturus.json: { "name": "my-app" }

04

Run it on your server

one command, idempotent

Clone, run one script — it installs dependencies, builds the dashboard and starts everything under pm2. Open http://<host>:7777 and you’re in.

On the first run you’re asked to set the admin password right in the terminal.

Bun 1.3+
Docker — only for container apps

$ git clone https://github.com/chussum/arcturus.git && cd arcturus
$ bun run server:up
  ✦ install → build → start   (pm2)
  ✦ first run asks for the admin password

# optional hardening (macOS) — plaintext keys → encrypted .env.secrets + Keychain
$ bun run secrets:init
  ✦ change a secret later → bun run secrets:update
  ✦ details → guide

05

Architecture

Bun workspaces monorepo

✦ apps/api NestJS — REST API, reverse-proxy gateway, deploy pipeline (runs on Bun)

✦ apps/web Next.js dashboard — Rspack + Linaria zero-runtime CSS, FSD architecture

✦ apps/cli arcturus CLI — single binary via `bun build --compile`

✦ packages/shared API contract types shared by api / web / cli

SQLite via Drizzle — repositories sit behind ports, so PostgreSQL is a module swap. Docker via dockerode behind a ContainerRuntime port. Static releases live in versioned directories; container releases are per-deployment image tags.