Skip to content
Super 1.7.0 is production-ready — transactional installs with automatic rollback, cron runtime caps (kill_after_secs), and panic-free input handling. See what’s new →

Quick Start

In this guide, we will start the Super daemon with a minimal configuration and use its REST API to dynamically register and start a demo HTTP server.

Note

Before adding programs: read the Managed Program Requirements — managed apps must run in the foreground and must not daemonize or escape Super’s process group.

1. Minimal Configuration

Create a file named super.toml. We only need to configure the server port.

# super.toml

[server]
host = "127.0.0.1"
port = 9002
# auth_secret = "…"   # optional on loopback; required for non-loopback binds

Caution

Default loopback bind keeps the API open for local CLI/scripts. Non-loopback binds require a non-empty auth_secret (or the daemon refuses to start). Multi-user Access Tokens need the security plugin. Prefer a firewall or reverse proxy if you expose the API.

If you use the repo’s example config, it also binds to port 9002 — keep CLI/API URLs in sync with your super.toml.

Note

Docker: the official schiplat/super image already ships a default super.toml under /app/super/conf/ — skip to step 2 and use the Docker tabs below for the demo program.

2. Start the Daemon (OSS)

Run the daemon in the foreground (default — required under systemd). Layout, config init, and --daemon: Installation — Instance layout and Start by hand.

superd

Without systemd, you may detach with superd --daemon (writes $SUPER_ROOT/run/superd.pid by default). Control programs and stop the daemon the same way either way (super …, super shutdown).

Expected output includes Super Core starting... and the listen address.

The OSS image is distroless — it runs superd + super only (no shell, no Python). Map the API port and the demo HTTP port. Give the container a name so you can run CLI commands later:

docker pull schiplat/super:latest

docker run --rm --name super \
  -p 127.0.0.1:9002:9002 -p 127.0.0.1:8080:8080 \
  schiplat/super:latest

The image binds 0.0.0.0 and ships placeholder auth_secret = "CHANGE-ME-BEFORE-EXPOSE" in the baked super.toml. Core auth is on — every business API call needs that Bearer (Dashboard login, super --token / super login, or Authorization: Bearer …). /health stays open. Replace the placeholder before publishing beyond the host. Details: Authentication.

# Host shell for steps 3–4 (matches the baked placeholder until you change it)
export SUPER_TOKEN=CHANGE-ME-BEFORE-EXPOSE

superd runs inside the container; the CLI does not have to. With -p 127.0.0.1:9002:9002, the HTTP API is on your host — use any option below for steps 3–4:

OptionWhen to use
curlZero install; copy/paste the REST examples
super --server http://127.0.0.1:9002 on the hostDay-to-day CLI (install the super binary from GitHub Releases, or docker cp it out of the image — see Installation — Docker CLI)
docker exec super super …Quick try without installing anything on the host

See Installation — Docker for custom mounts and subscription plugins.

Confirm the daemon is up before continuing:

curl http://127.0.0.1:9002/health
# {"status":"healthy","components":{"manager":"up","persistence":"up","web":"up"}}

Note

The /health endpoint is an unauthenticated liveness probe — it only says the API is reachable. On default loopback OSS, the REST API is open on the same port. With core auth (auth_secret set) or the security plugin, business endpoints require a Bearer while /health stays open.

3. Create Program via API

Open a new terminal. Pick the example that matches how you run superd:

Important

The schiplat/super image does not include Python 3. If you start Super with Docker, use the Docker tabs — not the Python example.

Requires Python 3 (install.sh, tarball, macOS, or Linux):

super add --name demo-web \
  --autostart python3 -m http.server 8080

On success, the API returns a JSON array with the new program ID.

4. Verify Status

super list
# demo-web should show Running or Healthy

Note

Docker: if superd runs in a container, auth is on — use super --server http://127.0.0.1:9002 --token "$SUPER_TOKEN" list or docker exec -e SUPER_TOKEN=CHANGE-ME-BEFORE-EXPOSE super /usr/local/bin/super list.

curl http://127.0.0.1:8080
# Python http.server: directory listing HTML
# Docker busybox httpd: often 404 on / — the port is up

5. Dashboard

Open http://127.0.0.1:9002.

OSS: The embedded Dashboard shell loads (process list, logs, stack editor). Optional core auth may prompt for login.

With subscription plugins: The ui plugin adds Pro surfaces (Access Tokens, Notification Settings, hot-reload) when security / notify are also loaded — see Dashboard.


Next Steps


Appendix: Licensed Plugins 💎

Licensed Super Pro capabilities (Dashboard Pro extensions via ui, token authentication & RBAC, resource isolation, event notifications, operation audit) ship as signed plugin libraries — .so on Linux, .dylib on macOS. They run on the same OSS superd and super binaries; there is no separate “Pro daemon”. Enabling licensed mode only adds three things from your subscription delivery:

PieceWhereNotes
[license].keyconf/super.tomlSigned license authorizing your plugins
auth_secretconf/super.tomlRoot bootstrap credential for first sign-in
Plugin libraries (security, ui, notify, isolation, …)$SUPER_ROOT/plugins/security is required — multi-user tokens / RBAC / audit
$SUPER_ROOT/
├── conf/
│   └── super.toml        # [license].key + auth_secret
└── plugins/              # authorized .so / .dylib (filenames match the signed claims)

$SUPER_ROOT is resolved from the SUPER_ROOT environment variable (then the binary layout, then the working directory).

Install and restart:

# 1. Copy the plugin libraries from your subscription delivery package
cp /path/to/subscription/plugins/* "$SUPER_ROOT/plugins/"

# 2. Add [license].key and auth_secret to conf/super.toml

# 3. Restart superd — it verifies the license, then loads the authorized plugins

Important

Licensed startup fails fast instead of silently losing API auth: security must load (file present and listed in the license claims) and auth_secret must be set — see Licensed deployments require security. Without a valid [license].key, superd runs in OSS mode and ignores plugins/.

First sign-in — with security active, bootstrap an Admin Access Token, then prefer sk-… tokens for day-to-day use:

super login <auth_secret>
super token create admin --role admin
super token list

Next. Day-to-day topics (config, auth, Dashboard) are under Essentials. Licensed governance (RBAC, audit, isolation, notify) is under Advanced Management. You can request a free 90-day Super Pro trial (Portal claim); compare editions in the feature matrix.

Was this page helpful? Thanks for your feedback!

Still have questions? Open an issue or browse the source.