Deploy what you have, as it is.

Five ways to start

New app asks one question first: what are you deploying? Pick the one that matches what you have; you can change your mind at any step.

Or start from the catalogue: ready-made apps that ask a few questions and fill in the rest. What you get is an ordinary app you can change later. Its secret answers are stored as your organisation's secrets.

Already running something? Adopt it. A container or a compose project already on a host becomes a managed app. Environment values are read once, and names that look like secrets are stored encrypted.

The last step of New app is a plan: what will happen, including the exact command BasePit will run. Nothing runs until you confirm it.

Paste the command you run today

Paste the line and BasePit proposes an app, with every correction it made listed for you to check:

# you paste
docker run --rm -p 60000:80 -e DB_PASSWORD=x -e DB_NAME=flyweb flywebapp

# what BasePit proposes, in short
✓ the port, the database name and the image tag become settings
✓ DB_PASSWORD becomes a secret, passed to the container by name only
✓ removed --rm, added -d and --restart unless-stopped, named the container

• A setting that names this app's own thing, such as DB_NAME, becomes a setting. One that says how to reach a shared service, such as DB_HOST, stays as it is.
• Anything it cannot work out is left empty and pointed out, never guessed.
• A pasted docker run can also become a compose app.

How each kind of app runs

# the header of a script app
# basepit:status   pidfile:%DIR%/run/app.pid
# basepit:logs     file:%DIR%/logs/application.log
# basepit:verbs    start stop restart deploy
# basepit:secrets  MONGO_URI STRIPE_API_KEY

The script holds no credentials: the names on the secrets line reach the process through its environment when BasePit runs it. State is read by the agent itself, from a container, a pid file, a process match or a URL, never by running a shell command. An image-update check compares a tag's digest in the registry with what each copy runs, and marks the app without pulling or restarting anything.

Releases

Every deploy, rollback, and scheduled stop or start is a release, with a record of who or what started it: a person, an API key, a redeploy URL, auto-update or a schedule.

• A copy counts as done only when its command finished and it came up healthy. An unhealthy copy is put back to what it ran before, and the release stops.
• You choose how many copies go at a time, what happens when one fails (stop, carry on, or undo the ones already done), a time limit per copy, how long to keep retrying, and whether to pull images first.
• One release per app at a time. If the controller restarts mid-release, the release is marked interrupted, and Resume continues from the first copy not finished.
• A deploy quiets the app's own alerts while it runs, and for a short grace after.

Deploys that start themselves

Automatic deploys respect change windows: a release from a redeploy URL or from auto-update waits for the next window to open. A schedule does not wait for one.

Settings, variables and secrets

• Variables are defined once for the account, an environment, a host group, an app or a single copy, and merged narrowest first everywhere an app's settings reach.
• A .env file imports: names that look like secrets, and credentials inside URLs, become secrets. An export shows secrets as ***.
• Secrets are sealed under your organisation's key and reach a process only through its environment. They are never written to a file, a command line or the console. A secret still in use cannot be deleted. Or read them from HashiCorp Vault or AWS Secrets Manager when the app starts.
• Config files are templates over an app's settings, written to an allowed path on its hosts before every start, restart and deploy. A secret never goes into one.
• Registries keep their credential sealed. The agent pulls with it in the request itself, and nothing is written to the host's Docker config.

Logs, terminal and files

• Live logs for each copy, read from the host while you watch. BasePit keeps no copy of them.
• Search every copy at once: an RE2 pattern of up to 200 characters, at most 2,000 lines, 20 copies and 30 seconds. The query itself is never stored.
• A terminal inside a managed container, on a host installed with --allow-terminal. Never the host's own shell. Admins only by default.
• A read-only file browser for a container's files, or a process app's working folder, on the same hosts. Downloads up to 64 MiB, recorded by path and size.
• Container events (stopped, out of memory, restarted, health changed) appear in Activity.
• Alert rules for apps: an app that stops, a health check that fails, a container restarting again and again, copies missing, and running out of memory.

Guardrails

Slack, e-mail and webhook channels can also be told when a release starts and ends. More on roles and access rules: Security.

Limits

• No scheduler. A group of hosts is an explicit, ordered list. BasePit places copies where you say.
• No autopilot. A stopped app is not restarted by BasePit. Containers keep Docker's own restart policy, and readiness shows apps without one.
• Drift in a compose file or a script header is shown, never applied by itself.
• The basepit command-line tool speaks BasePit's REST API. It does not forward ports.