How do our people log in, and how do we control what the agent can touch?

Through Papercrane with SSO: Google, Microsoft, and Okta. Access is per user and per workspace in every deployment shape. What the agent may read, write, or delete is set per connection, and every action lands in the audit log.

Enterprise BYOC

Run Papercrane in your own cloud.

Q: What leaves our cloud?

Workspace metadata: names, who is logged in, dashboard definitions, chat history, and health signals. Data source credentials, query results, and dashboard files stay in your cloud. When someone opens a dashboard, the page is served from your cloud to their browser through our authenticated proxy, encrypted in transit and never written to disk on our side.

Q: Which clouds and runtimes do you support?

AWS, Azure, and GCP. Containers on ECS Fargate or any container runtime. Kubernetes on EKS, AKS, GKE, or any conformant cluster with a private API endpoint. Cross cloud is normal: the runtime in Azure and the warehouse in GCP works without peering. Other shapes on request.

Q: Do we need to open inbound ports, peer a VPC, or set up PrivateLink?

No. Outbound HTTPS on 443 plus one UDP port for the mesh, through the NAT path you already use to pull container images. No inbound rules, no public endpoints, no peering, no PrivateLink, no load balancer to protect.

Q: Can we run more than one region or cluster?

Yes. One deployment per region or per business unit. Each registers on its own and has its own network identity.

Containers in your AWS, Azure, or GCP account, or a Helm chart in your Kubernetes cluster. Compute, credentials, and queries stay inside your boundary. The only connection is outbound.

Talk to us about deployment Try Papercrane Cloud first

SOC 2 and HIPAA compliant, every deployment shape in scope.

Your cloud: containers

AWS, Azure, GCP

Boundary: You

Your cloud account

Your data sources

Credentials stay in your secrets store

Papercrane agent

A task in your container service

Dashboards

Rendered on your compute

Queries, credentials, and results stay inside this box.

OUTBOUND ONLY · 443 · NO INBOUND

Papercrane control plane

Orchestration, the UI, login

Your cloud: Kubernetes

Helm chart

Boundary: You

Your cluster, one namespace

Your data sources

Credentials stay in your cluster secrets

Papercrane agent

A pod in your namespace

Dashboards

Rendered inside the cluster

Queries, credentials, and results stay inside this box.

OUTBOUND ONLY · 443 · NO INBOUND

Papercrane control plane

Orchestration, the UI, login

Same product in all three. The dashed box is the boundary. Only one line crosses it, and it points out.

How does it work?

Your data stays in your cloud.

Where does the AI run?

In your cloud. The agent runs as a container or a pod inside your account, next to your warehouse and your tools. Querying, building, and scheduled runs all happen there.

Your account

Containers or Kubernetes

Runs next to your data

Where do the data and connections live?

Also in your cloud. Connection credentials sit in your secrets store, queries run against your sources in place, and results render inside your account. Nothing is copied out.

Your secrets store

Queried in place

No copy leaves

How access rules work →

How do your people connect?

Through Papercrane. Your team signs in with Google, Microsoft, or Okta, and our control plane routes them to your agent over its outbound link. We handle login, the interface, and sharing. We don't hold your data.

Routed to your agent

We hold no data

Getting set up.

Three steps, in the order your team will do them.

Pick your shape.

We issue your deployment's network identity and an install package for your shape: a CloudFormation stack for containers, or a Helm chart for Kubernetes.

CloudFormation stack

Helm chart

Network identity

Deploy. It dials out.

The stack or chart creates one namespace or service, persistent storage, secrets, and the agent. On boot the agent registers with our control plane over the outbound mesh and the workspace shows up in the UI. Nothing to expose.

One package

Registers on boot

Nothing exposed

Connect data, set rules, build.

Credentials go into your secrets store, never into ours. Set read, write, and delete rules per connection, then your teams build and share dashboards exactly as they would in our cloud.

Credentials in your store

Rules per connection

Same product

Sharing, embeds, and custom domains →

What runs where.

The pieces a review asks about, side by side. Rows in white stay inside your boundary. Rows in grey are ours in every shape.

Piece	Your cloud: containers	Your cloud: Kubernetes
Agent compute	A task in your container service	A pod in your namespace
Data source credentials	Your secrets manager	Your cluster secrets
Query execution	Your compute, your network path to the data	Your cluster, your network path to the data
Dashboard runtime	Your compute	Your cluster
Dashboard code	Your persistent storage and your git repo	Your persistent volume and your git repo
AI model calls	From your cloud, on your model provider account	From your cloud, on your model provider account
Orchestration: create, start, stop, health	Papercrane	Papercrane
Web UI and login (Google, Microsoft, Okta)	Papercrane	Papercrane
Sharing, embeds, custom domains	Papercrane	Papercrane

Sharing details live on their own page:

share a live dashboard

The network model.

One outbound connection from your cloud to our control plane. Nothing comes in.

Direction

Outbound only, from your cloud to us

No inbound rules, ever

Ports and endpoints

443 out plus one UDP port for the mesh

No public endpoints in your account

Transport

Encrypted private mesh, WireGuard based

Not VPN peering, not PrivateLink

Identity

One network identity per deployment

Only our control plane may reach it

The browser side is the same in every shape: people open dashboards through our authenticated proxy, which reaches your runtime over the same mesh. Encryption, sessions, and audit are covered on the security page.

What you need on your side.

Both shapes need the outbound path you already allow for pulling container images. That is the whole network ask.

Containers

Any container runtime on AWS, Azure, or GCP on request.

A cloud account and a container service

Our CloudFormation stack: storage, secrets, roles, task definition

Outbound HTTPS from the task

Your model provider account

Kubernetes

EKS, AKS, GKE, or any conformant cluster. A private API endpoint is fine.

kubectl access for the one time helm install

One namespace. No ingress controller, no load balancer

Outbound 443 and one UDP port from the nodes

2 vCPU and 4 GB per workspace to start

Onboarding is short.

One package to run, and we sit in your security review with you.

Step 1

Scoping call

Cloud, region, data sources, and who holds which credential. You leave with your install package and your deployment's network identity.

Step 2

You deploy

Run the stack or the chart. The agent registers over the outbound mesh and the first workspace is live in the UI.

Step 3

Connect and review

Credentials into your secrets store, access rules set per connection, first dashboard built. Your security review gets the audit log and the boundary map above.