BasePit

Security

What BasePit can do on your machines, and what it cannot.

An agent on a production server should be easy to reason about. This page sets out the rules BasePit is built on: what the agent does by default, what the machine's owner can switch on, where every credential lives, and what is recorded.

Declared inventoryOpt-in at the machineSecrets never shown or loggedEvery action recorded

The model in brief

The machine

Its owner decides

The agent runs only what you registered with it. Anything more is an install flag set on the machine itself, and the console can never switch one on.

The organisation

Nothing crosses

Every record belongs to one organisation, and its secrets are sealed under that organisation's own key.

The person

Roles, then narrower

Viewer, Operator and Admin, with access rules that can take rights away and never add them.

The record

Every action

Who did what, and when, in Activity. Terminals are recorded when they open and close, never what was typed.

The agent runs what you registered

The agent knows only the apps registered with it, and can only run the recipes registered for them: start, stop, restart, deploy. There is no code path that runs an arbitrary string. Services on the same machine that BasePit does not manage, such as a database or a cron job, are invisible to it and untouchable.

Six features need a session into a machine. Each one is an exception the machine's owner turns on, and each one has the same edges: it opens only into something the agent itself manages or sees, with a fixed command, recorded when it opens and closes, and never a byte of it logged.

SessionNeedsOpens into
A container's terminal--allow-terminal on the hostA container of an app the agent manages. Never the host's own shell.
A pod's terminalTerminal allowed when the cluster agent was installedA pod and container the cluster agent can see.
A RHEL unit's terminal--allow-terminal on the serverA Podman unit BasePit made. Never one made by hand on the server.
A Proxmox container's terminal or VM's screen--allow-terminal on the nodeA guest running on that node.
A Windows VM's screen--allow-host-control on the hostA Windows VM BasePit made on that host, through a socket inside its container. No VNC or web port exists on any network.
An AI coding agent's session--allow-host-control on a Linux hostThe agent's own CLI, started with flags from a fixed table. A message you type is never turned into a flag.

What each install flag allows

Each flag goes on the install line, on the machine, by whoever has root there. The console shows what a machine allows, and cannot change it.

FlagAllowsLimits
(none)Deploy, start, stop and restart the apps you register; their logs and measurements; checks of your private monitors.Nothing outside the apps you registered.
--allow-terminalA terminal into a managed container, a read-only file browser for managed apps, and the RHEL and Proxmox terminals above.Admins only by default. Downloads at most 64 MiB, recorded by path and size, never content.
--allow-host-controlHost insight: servers listening, processes, GPUs, systemd services and host logs. Start, stop or restart a service, switch its start at boot, stop or kill a process. Look for machines on the host's own network. Make VMs on Linux. Run AI coding agents on Linux.See the refusals below. Host logs only under /var/log. Network looks only on the host's own private networks, never a public or link-local address, and a sweep covers at most 1,024 addresses. A Mac shows servers, processes and GPUs only.
--allow-automationRun Ansible playbooks from this host, against itself and against machines without the agent.Linux hosts only; refused on a Mac and on a worker. Playbooks run as root, which is why it is the owner's call.
--allow-buildsBuild images from Git or an uploaded folder with this host's Docker, and push them.A build runs a Dockerfile through root's Docker daemon. The registry credential is passed only to that command.
--allow-tasksRun Toolbox checks on this machine.Linux only; each check in a locked-down container (see the sandbox).
--allow-openshift-installMake OpenShift or OKD install images on this host.Linux hosts only; refused on a worker.

A cluster agent's choices are made the same way, when it is installed: how far it reaches (the whole cluster or listed namespaces), whether it is view only, and whether pod terminals are allowed.

Built-in refusals

Some actions are refused whoever asks, because the agent or the controller checks them itself.

  • Host control refuses PID 1, BasePit's own agent (its unit, its process and its process group), and any process or service of an app BasePit manages, which keeps its own Stop and Restart. Each action is a fixed command on a unit or process the agent lists at that moment, recorded without a command line.
  • VMs are made by the host's agent alone, from images pinned by digest, and the agent acts only on VMs in its own record, never on a container a message names.
  • Cloud machines are made in your own cloud account. BasePit acts only on machines its own make recorded, never on one found by name, and a made machine gets no extra install flags.
  • Proxmox: no Proxmox password or token is typed into BasePit. A VM's screen uses a one-time password the agent makes and answers itself, so the browser is never given one. Proxmox's protection flag is honoured and never cleared, BasePit never deletes a guest on its own, and it never updates or reboots a node.
  • RHEL: BasePit never installs an update, reboots, changes SELinux's mode, or starts and stops firewalld. It changes an SELinux boolean only as the fix a denial names, and edits only files that carry its own marker.
  • Kubernetes: every change is a named action that both the controller and the cluster agent check. A Secret's values never leave the cluster.
  • Deleting a VM, a Proxmox guest or a cloud machine asks you to type its name.

Where each credential lives

CredentialHow it is kept
A machine's node secret32 random bytes, encrypted on the machine's record. The machine holds the only plaintext copy in a private file, and proves it with an HMAC over a fresh challenge on every connect. It is replaced with New secret.
Install tokenWorks once, expires in an hour, shown once. Passed to the agent as a private file, never as an argument or in a URL.
Enrol key (many machines)Stored only as a hash. Revoke it once your machines have joined.
Heartbeat and redeploy URLsThe token in each is shown once and stored only as a SHA-256 hash. An unknown heartbeat token gets an empty 404, so nothing can be probed.
App secretsSealed under your organisation's key, handed to the process in memory, never shown again. A secret still in use cannot be deleted.
Vault and AWS Secrets ManagerRead when an app starts, held in memory for 60 seconds, stored nowhere.
Registry, Git and cloud credentialsSealed under your organisation's key and never shown again. A registry credential is used in the pull itself and never written to the machine.
AI coding agent keysSealed, and given only to the agent session that reads it, through its environment. A Git token for a box reaches only a short-lived helper container, never the box where the AI works.
Webhook signing secretShown once. Each delivery carries an X-Basepit-Signature header with a timestamp and an HMAC-SHA256, and receivers refuse one more than five minutes old.

How a secret travels from BasePit into a running process is on How it works.

Organisations are kept apart

  • Every record BasePit keeps carries the organisation it belongs to. A record of another organisation is answered as not found.
  • Secrets are sealed under a key derived for each organisation, and uploaded files are kept in a folder per organisation.
  • Your personal account and an organisation you belong to are separate: separate fleets, separate secrets.

Who can do what

  • Roles: a Viewer reads everything, an Operator starts, stops and deploys, and an Admin can change everything.
  • Access rules narrow what a person or a team may do on an environment, a host group, a tag or an app. They are checked on every request and every live message, and they can never widen a role.
  • Teams own apps, hosts and monitors, and alerts can go to the owning team.
  • Approvals: an environment can require up to five approvals before a release goes out. The person who started it never counts, and one rejection cancels it.
  • Locks and change windows hold releases and settings changes. A lock still allows start, stop and restart.
  • Policies refuse, per environment, host group or tag, an image from an unlisted registry, host networking, a mount outside allowed folders, a missing health check or owner, or a container running as root.
  • New hosts can wait for approval before they run anything, if your organisation turns that on.

What is recorded

Activity records every action: who, what, on which thing, and when. Some are recorded with care for what they must not keep:

  • Terminals and screens: when they opened and closed, never their contents.
  • Host actions: which service or process, never a command line.
  • File downloads from the browser: the path and the size, never the content.
  • Log searches: the query is never stored, only its length.

Anyone can export Activity as CSV or JSON. Accounts that have bought credits can also stream it to a SIEM, over syslog with TLS or signed HTTPS.

Security checks run in a sandbox

Each Toolbox check runs as one container:

  • as an unprivileged user, with a read-only root file system and every Linux capability dropped;
  • from an image pinned by digest;
  • for a fixed time limit, after which it is stopped.

On BasePit's workers, checks run in rootless Podman as their own user, behind a network fence that drops traffic to private, loopback, link-local, carrier-grade NAT, multicast and cloud-metadata addresses after DNS. The worker checks the fence before every task and refuses to run without it.

A check that reads only what any visitor could read runs on any public target. A check that probes deeper runs only on a domain your organisation has proved it owns, with a DNS TXT record or a file under /.well-known/, checked again every 30 days.

Signing in and paying

  • You sign in with your BasePit account: email and password, Google, or Slack.
  • Two-step sign-in with an authenticator app, with recovery codes for when the phone is not at hand.
  • "Forgot password" answers the same whether or not an account exists, so the page cannot be used to find out who has one. Reset links work once.
  • You pay on the payment provider's own page, and BasePit never sees your card. Credits are added only after BasePit's own server has confirmed the payment with the payment service. Nothing the browser sends can add them.

What BasePit cannot do

  • Connect in to your machines, or open a port on them.
  • Run a command that is not a registered recipe, outside the six sessions above.
  • Switch on an install flag from the console.
  • Act on a host's own services and processes unless its owner allowed host control, and then never on PID 1, its own agent, or an app it manages.
  • Show you a secret again after it is set, or read a Kubernetes Secret's values.
  • Act on a cloud machine or a VM it did not make, delete a Proxmox guest on its own, or update or reboot a Proxmox node or a RHEL server.

Your first host is a minute away.

Sign up, paste one line, and watch it turn green. No card, and one server free for good.