Deploy

Building and running apps.

Detection

Pando reads the source and works out how to build and start the app and which services it needs.

Trial runs

Pando starts the app in a throwaway container to find the port it actually listens on.

Proposals

You review what Pando detected before it builds. Anything it couldn’t work out is asked as a question.

Sandboxed builds

Builds run in a rootless builder with no access to the host or to other apps.

Access

Who can open and manage each app.

Sign-in

Apps are private by default. Share one with people or groups, or make it public.

Signed identity

Apps receive a short-lived signed token describing the visitor.

SSO and SCIM

Sign in through any OIDC provider and provision users and groups with SCIM. Included at no extra charge.

Accounts, groups and roles

Four built-in roles, plus custom roles made from individual permissions.

Use and admin are separate

Being able to open an app and being able to change it are separate grants.

Security

Scanning and scoring every build.

Scans

Every build is checked for vulnerable dependencies, leaked secrets and misconfiguration.

Security score

Each app gets a score from 0 to 100 based on what the scan found.

Minimum score

Host policy can block deploys below a score, with a grace period for apps already running.

Scan history

Scans are kept per revision, so rolling back also restores that revision’s score.

Data

Databases, secrets and storage.

Databases

Postgres, MySQL and Redis per app, with credentials generated and injected.

Secrets and variables

Set per app.

Volumes

Persistent storage per app, kept across redeploys.

Backups

On demand, and automatically before an app is deleted.

Operate

Logs, shell access and rollback.

Logs

Build and runtime output in one stream, in the console or with pando logs --follow.

Terminal

A shell in a running container, from the console or with pando exec. Host policy can turn this off.

Rollback

Return to any previous configuration.

Resource limits

Set per app.

Govern

Rules and records for the whole installation.

Host policy

Allowed sources, whether apps can be public, minimum isolation, an egress allowlist, required backups, token lifetime and disabled actions.

Audit log

Every action and who did it. Pando’s database role has no UPDATE or DELETE on the table.

Bundles

Each app and its services run together on a private network that other apps can’t reach.

Single entry point

All traffic to apps goes through Pando’s proxy.

Providers

Adapters for the services you already use.

Routing

Put Cloudflare, Traefik or another router in front of Pando.

Hosting

Run apps on Docker locally or on a cloud provider like AWS.

AI

Choose the model provider, such as Anthropic, for Pando’s AI features.

Identity

Sign in through Okta, Google or any other OIDC provider.

Scanning

Trivy by default, or another scanner.

Interfaces

Ways to use Pando.

Console

A page of app tiles for people who use apps, and an admin interface for people who manage them.

CLI

Available through Homebrew, .deb, .rpm and .apk packages, or go install.

MCP server

Ten tools for coding agents, limited to your permissions.

HTTP API

Session or bearer token auth. Errors include a code, a message and a suggested fix.

Limits

What the current version doesn’t do.

  • An installation runs apps on one host. It doesn’t schedule across machines.
  • An installation serves one organization.
  • There’s no multi-region support.
  • There’s no replication or autoscaling, and it isn’t built for services that need 99.99% uptime.