Features · Pando

Deploy

Git sources: Deploy from any git host, such as GitHub, GitLab, Azure DevOps or Bitbucket, including self-hosted ones.
Private repositories: Connect a host once and deploy its private repositories. Every clone is audited.
Uploads: Deploy a local directory or archive from the CLI, the console or MCP.
Published images: Deploy an image straight from a registry, including private ones.
Auto-deploy: Deploy on a new commit or release tag, when you opt in.
Plans: See what a deploy will do, and anything that would block it, before it runs.
Deploy approval: Require someone to approve a deploy before it runs.
Reproducible deploys: Every deploy is pinned to an exact commit and image.
Revisions: Every configuration change is a revision you can compare and roll back to.
Safe failures: A failed build leaves the running version in place.
Export: Export an app’s configuration without its secrets.

Detection: Pando reads the source and works out how to build and run it.
Many inputs: Builds from Dockerfiles, Compose files, Procfiles, build scripts and CI build jobs.
No Dockerfile needed: Builds common languages and static sites without one.
Compose import: Brings in a Compose app’s services, start order, health checks, volumes and secrets.
Unsafe settings refused: Settings that would weaken isolation are refused, with the reason shown.
Trial runs: Starts the app in a throwaway container to see how it actually runs.
Proposals: Review what was detected before it builds. Anything Pando can’t tell is asked as a question.
Re-detection: Run detection again when you choose, without losing decisions you made.
Rootless builds: Builds run rootless in their own container, with no access to the host’s container runtime.

Runtime adapters: Run apps on one host, across several hosts, or on a cluster, such as Docker or Kubernetes.
Sandboxing: Run apps under a sandboxed runtime, such as gVisor or Kata.
Self-healing: Containers that stop or disappear are restored.
Crash handling: An app that keeps crashing backs off and is marked failed until someone acts.
Health checks: Checks that each part of an app is healthy.
Usage: CPU, memory and disk for each part of an app, beside its limits.
Resource limits: Defaults for the installation, with overrides per app.
Capacity: Deploys that would overload the host are refused.
Disk limits: Apps that use more disk than allowed are warned, then stopped.
Idle apps: Stop or remove apps nobody uses, with notice first.
App limits: Limit how many apps a person or group can own.

Identity-aware proxy: Every request to every app goes through Pando.
Private by default: Share an app with people or groups, or make it public.
Passcodes: Make an app public behind a passcode.
Identity headers: Apps are told who is visiting, with a signed token they can verify.
SSO (OIDC + SAML): Sign in through an identity provider, such as Okta, Microsoft Entra ID or Google.
SCIM: Provision users and groups from your identity provider. Deprovisioned people are suspended, not deleted.
Just-in-time accounts: Create accounts on first sign-in, when you opt in.
Password sign-in: Turn it off once an identity provider is set up.
Roles: Built-in roles, and custom roles made from individual permissions.
Use and administer: Opening an app and managing it are separate permissions.
Tokens: Personal and service tokens for the API, CLI and agents.
Launcher: A home page of the apps each person can open.

Vulnerability scanning: Scans each app for vulnerable dependencies, leaked secrets and misconfiguration.
Security score: Each app is scored on what its scan found.
Minimum score: Block deploys below a score you set.
Scan history: Scans are kept per revision.
Network isolation: Each app runs on its own private network that only Pando can reach.
Egress controls: Control where apps can connect out to.
Header stripping: Forged identity headers are replaced, and Pando’s own cookies and tokens never reach an app.
Secrets: Encrypted at rest and redacted everywhere. Reading one is its own permission.
Terminal controls: Terminal sessions are audited, and policy can turn them off.
Agent limits: Limit what tokens used by AI agents can do.
Rootless: Pando runs on rootless Docker or Podman.

Databases: Provision a database for an app, or connect one you already run.
Variables and secrets: Set per app.
Volumes: Persistent storage that survives redeploys and the app being deleted.
Volume suggestions: Pando warns when an app writes data that isn’t on a volume.
Backups: Scheduled backups per app, restored in place.
Final backup: Taken when an app is deleted.
Full backup: An encrypted backup of the whole installation.

Routing adapters: Reach apps on local ports, or through a router or tunnel, such as Traefik or Cloudflare Tunnel.
Addresses: Subdomains, paths or ports, with custom hostnames.
Certificates: Certificates issued and renewed automatically.
Sign-in on the app’s address: Visitors sign in without leaving the app’s hostname.
Streaming: Websockets and server-sent events pass through the proxy.

Logs: Build and runtime logs, live in the console or the CLI.
Terminal: A shell in a running app, from the console or the CLI.
Audit log: Every action and who took it. Entries can’t be changed.
Audit export: Stream, export and archive the audit log.
SIEM: Send audit events to a SIEM, such as Splunk, Datadog or Microsoft Sentinel.
Events and webhooks: Send events to signed webhooks.
Notifications: Notify people in the console, by email or in chat, such as Slack or Microsoft Teams.
Metrics: Pando’s own metrics over OpenTelemetry.
High availability: Run several Pando instances against one database.

Host policy: Set rules for the whole installation, such as allowed sources, public sharing, egress and approvals.
Policy as config: Fix policy in a file or environment variable.
Policy preview: See which apps a policy change would affect before saving it.

AI adapters: Use a hosted or local model, such as Anthropic, OpenAI or Ollama. Optional.
Detection help: Fixes failed plans and answers detection’s questions, citing the files it used.
Drafting: Drafts roles, groups and policy for you to review.
Audit search: Turns a question into an audit log search.
Answers: Answers questions about using Pando.
Audited calls: Every call to a model is recorded in the audit log.

API: Everything Pando does, with a reference generated from the code.
CLI: Installed through common package managers, with signed self-update.
MCP server: Tools for coding agents, limited to the token’s permissions.
Console: The launcher, an admin page for each app, and settings for the installation.

Compose install: Pando and its database from one Compose file.
Kubernetes: Run Pando on a cluster.
Updates: See what changed in each release.
In-place upgrade: Signed upgrades, backed up first and rolled back if the new version doesn’t start.