Not yet
Certification
No SOC 2, no ISO 27001, no HIPAA.
In its place
This page: the substance those reports summarise, in a form you can check against the product rather than take on trust. We will not imply otherwise with a badge.
Security
You are installing an agent in your own cluster.
That is a bigger ask than signing up for a hosted platform. So here is what the agent can do, what crosses the boundary, and where we stand on certification, including the parts that do not flatter us.
What the agent can do →No cluster of your own? Anyport Cloud
- Inbound ports openedNone
- Kubeconfig shared with usNever
- Agent privilegeCluster admin
- HTTPS decrypted by usNever
- App logs we keepNone
- Secret values at restAES-256-GCM
- Audit log kept90 to 365 days
- CertificationNot yet
01Connection
One connection, opened from your side.
The agent dials out over TLS and holds that connection open; your changes travel back down it. You open no port, publish no API server, and need no public IP.
Stays in your cluster
- Your kubeconfig and your API server
- Your source code, and every build of it
- Logs and metrics, where they are stored
- TLS keys, and your traffic in the clear
One connection, opened by your cluster
- Status, as the agent reports it
- Your changes, back down the same line
- Logs and metrics, while you have them open
- Sealed HTTPS, for clusters with no public IP
Held by Anyport
- The configuration you enter, and its status
- A SHA-256 hash of the agent token
- Secret values, sealed with AES-256-GCM
- An audit log of every change
No kubeconfig leaves your cluster
We never receive credentials for your Kubernetes API, so Anyport cannot reach your cluster on its own. If the agent stops dialling out, our access ends with it.
The token is shown once
The install command carries a token we keep only as a hash, so no API can read it back. Lose it and you regenerate, which invalidates the copy you lost.
You can cut it off
Uninstall the agent's Helm release and the connection is gone. Your apps keep running, because they are ordinary Kubernetes objects that do not depend on us.
02Permissions
Broad privilege, scoped behaviour.
Read this part before you install anything. The agent runs with full cluster privileges, and in practice acts only on the namespaces it created.
Can reach
every resource · every verb
- project-shopacts here
- project-apiacts here
- monitoring
- payments-legacy
- kube-systemnever
- defaultnever
Its own namespaces, labelled by the project controller.
Everything else. No terminal, port-forward or log stream opens here.
neverRefused even if someone copies our labels onto it.
Every verb on every resource
The agent's ClusterRole lets it create namespaces, workloads, secrets, storage and operators anywhere in the cluster. That is what makes one-click databases and managed ingress work, and it means the agent can do anything there.
Treat it as an administrator
Install it where that is acceptable. To evaluate Anyport, use a cluster that runs nothing you cannot afford to have touched.
It checks before it opens a door
Before a terminal, a port-forward or a log stream, the agent re-checks the namespace's labels for itself. A command from the console is a request, not an instruction.
Upgrades are yours to approve
You roll the agent forward from the console and we publish what changed. A fleet does not drift onto a version you did not choose.
03Data
Your HTTPS stays sealed through us.
A cluster with no public IP is published through our gateway, which routes on the server name and never terminates TLS. We hold none of your certificates and see none of your traffic in the clear.
A visitor's HTTPS
Anyport gateway
Reads the server name in the handshake, then forwards the bytes.
Your agent
Carries them down the connection your cluster opened.
Your ingress
Holds the certificate, and is the first to decrypt.
One destination
The connection your cluster opens can only be forwarded to your own ingress controller. The agent reads that destination from your cluster, never from us, so nothing we send down it can reach anything else.
Two structural exceptions
Plain HTTP on port 80 is unencrypted by definition, and we proxy the ACME challenge requests that let your certificates be issued. A cluster with its own public address skips us entirely.
Logs and metrics, while you look
Both are collected and stored in your cluster. A log tail or a metrics panel streams that window to your browser through us; close it and nothing further is sent.
Builds stay put
Source is cloned and images are built by your cluster, on your hardware. Build output is not shipped to us.
04Storage
What a copy of our database would show.
Values inside a project secret are encrypted with AES-256-GCM before they are written. Plaintext exists only in memory and on the TLS connection to your agent.
A project secret, as the database holds it
- STRIPE_SECRET_KEYkenc.v1.k1.9bQ2xLmV0p_Tz4rA8kWcN1eHs6YdJf3uRt
- DATABASE_URLkenc.v1.k1.Hq7Ue2-ZnR5vXc0LtPw9aKm4SgBy1oDjVe
- SMTP_PASSWORDkenc.v1.k1.rC3wYk8Nf_0aLzT6pVq2EhJm9uXs4bGdLw
NAME in the clear, so the console can list it.
k1 is the key that sealed it, so keys rotate without re-encrypting everything.
The rest is the nonce and ciphertext. Values here are made up; the shape is exact.
The threat model is storage
A database dump or a volume snapshot should not hand anyone every customer's credentials. It is not a claim that Anyport staff can never see a decrypted value.
Reading a value back is deliberate
The console lists names. Revealing a value needs edit rights on that secret, and every reveal is in the audit log.
Tokens are kept as hashes
Agent tokens, CI service tokens and sign-in sessions are stored as SHA-256 hashes, so a copy of the database replays none of them.
05Access
Who can do what in your organization.
Three roles, refined per cluster and project. Every delete path checks permission before it does anything.
| Role | Admin | Developer | Viewer |
|---|---|---|---|
| See projects, apps and their status | Yes | Yes | Yes |
| Deploy, change and delete apps and projects | Yes | Yes | No |
| Connect or change a cluster | Yes | Yes | No |
| Reveal a secret value | Yes | Yes | No |
| Open a terminal or forward a port | Yes | 1Yes, unless the organization turns it off | No |
| Delete a cluster | Yes | No | No |
| Protect or restrict a cluster or project | Yes | No | No |
| Invite and manage members | Yes | No | No |
Protected and restricted
A production cluster or project can be protected, so members can look but not change it, or restricted, so it does not exist for anyone not granted access. Only admins change either, and each change is audited.
Terminals are their own grant
A shell into a container defeats most other restrictions, and a port-forward reaches whatever is listening, so both run the same checks. Limit them to admins, or switch them off for the whole organization, which also closes every open session.
Audit log
Every change, with the account behind it and whether it came from the console, the CLI or an MCP client. Entries are kept 90 days; terminals, port-forwards and secret reveals are kept for a year.
Sign-in
Through Auth0, with a verified email before an account can do anything. CI signs in with a service token that carries a role of its own. A self-hosted control plane uses your own identity provider.
06Anyport Cloud
What changes when we run the cluster.
Everything above describes a cluster you attach. On Anyport Cloud the hardware is ours, so several of those answers change. Here they are side by side.
A cluster you attach
Anyport Cloud
- The hardware
- AttachedYours, wherever it runs.
- Anyport CloudOurs. The people who run our hosts have root on the machines.
- Reaching inside
- AttachedOnly through the agent you installed. No kubeconfig of yours reaches us.
- Anyport CloudWe can. Our provisioner holds a credential for each host, sealed at rest, and reads your cluster's admin credential to build and upgrade it. There is no connection to cut: deleting the cluster ends it, with everything in it.
- Isolation
- AttachedWhatever your nodes and runtime already enforce.
- Anyport CloudEach cluster is its own Kubernetes control plane in its own namespace on a shared host, and every pod runs under gVisor, a user-space kernel between your code and the host's. A node without the sandbox accepts none of your pods.
- Network
- AttachedYour network, under your own rules.
- Anyport CloudYour pods cannot reach private or link-local networks, where other clusters, our nodes and cloud metadata live, nor outgoing mail ports or a node's own services. Inbound, only your own cluster and the node's health probes reach them directly; everyone else comes through your public HTTPS addresses.
- Where TLS ends
- AttachedAt your ingress, on your machines.
- Anyport CloudStill at your cluster's own ingress, after the host's edge routes on the server name. But that ingress, and its private keys, run on machines we operate.
- Logs, metrics, builds
- AttachedStored in your cluster, streamed only while you look. Builds run on your hardware.
- Anyport CloudLogs and metrics sit in stores a host's clusters share, each record labelled with its cluster and every read, the console's included, scoped to one. Logs are kept 7 days, metrics 15. Builds run inside your cluster, which here is our hardware too.
- Storage
- AttachedYour disks, your backups.
- Anyport CloudVolumes are LUKS-encrypted on the host. Control-plane state, including its Kubernetes Secrets, is snapshotted to object storage we run, so a lost control plane is restored rather than rebuilt.
- Upgrades
- AttachedYou approve each agent upgrade from the console.
- Anyport CloudWe upgrade in waves, each after a snapshot and announced a day ahead. A routine upgrade can be deferred once, by 14 days. A security upgrade cannot.
07Assurances
Where we stand today.
The assurances an independent vendor is expected to carry, and which of them we do not carry yet. If one is a hard gate for you, say so and we will tell you straight whether we can meet it.
Not yet
External audit
No third-party penetration test, and no bug bounty programme yet.
In its place
Vulnerability reports are read first by the person who built the agent, and worked through with the reporter rather than left in a queue.
Not yet
Uptime SLA
No uptime commitment on the console, and none implied here.
In its place
Structure, not contract: your workloads are ordinary Kubernetes objects in your own cluster, so they keep serving while our control plane is unreachable, and you keep kubectl throughout. That fallback belongs to clusters you attach. On Anyport Cloud a failed host is an outage until we restore it, and no commitment covers that either.
Found something? Tell us first.
Two inboxes for two different jobs, both read by a person.
A vulnerability
security@anyport.devTell us before you tell anyone else and we will work it with you. Or use the contact form and say it is a security report. Either is read first by Abdhesh Nayak, who built the agent.
Abuse
abuse@anyport.devFor content served through an Anyport-published hostname, acknowledged within one business day. On a cluster a customer attaches we route to their machines rather than host their content, so our remedy is to stop publishing a hostname. On Anyport Cloud we host it, and can also suspend the cluster.