Security
You are installing an agent in your own cluster.
That is a bigger ask than signing up for a hosted platform, so this page states exactly what Anyport connects to, what the agent is allowed to do, what data crosses the boundary, and what we do not have. Some of it is unflattering. It is all checkable.
How Anyport reaches your cluster
One outbound connection, opened by your side, and nothing else.
- No inbound ports
- The agent dials out to Anyport over TLS and keeps that connection open. Work travels back down it. You open no ports, publish no API server, and need no public IP.
- No kubeconfig leaves your cluster
- We never receive credentials for your Kubernetes API. Anyport cannot reach your cluster on its own — if the agent stops dialling out, our access ends with it.
- We store the agent token as a hash
- The install command carries a token that is shown to you exactly once, because only its hash is kept. There is no API that 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.
What the agent can do
This is the part to read carefully before you install anything.
- It runs with full cluster privileges
- The agent's ClusterRole grants all verbs on all resources. It creates namespaces, workloads, secrets, storage and operators across the cluster, which is what makes one-click databases and managed ingress possible — and it means the agent can do anything in that cluster.
- Treat it as an administrator
- Install it in a cluster where that is acceptable. If you are evaluating Anyport, use a cluster that is not also running something you cannot afford to have touched.
- It only acts on Anyport's own resources
- In practice it reconciles the namespaces Anyport creates, which are labelled and owned by the project controller. The terminal feature independently re-checks those labels on the agent side before it will open a session — the privilege is broad, the behaviour is scoped.
- It updates itself
- You approve agent upgrades from the console. We publish what changed; a fleet does not silently drift onto a version you did not choose.
What leaves your infrastructure
- Resource state
- The configuration you enter in the console and the status the agent reports back: apps, projects, domains, revisions, health. This is the state Anyport exists to hold.
- Logs and metrics, only while you look at them
- They are collected and stored inside your own cluster. Opening a log tail or a metrics panel streams that window to your browser through Anyport. Close it and nothing further is sent; we do not warehouse your logs.
- Application traffic stays encrypted end to end
- A cluster with its own public address serves traffic directly and never touches us. A cluster with no public IP is published through our gateway, which routes on the server name in the TLS handshake and forwards the encrypted bytes untouched. It never terminates TLS, so we hold none of your certificates and see none of your traffic in the clear. Your cluster's own ingress terminates HTTPS, exactly as it would without us. The exceptions are structural: plain HTTP on port 80 is unencrypted by definition, and we proxy the ACME challenge requests that let your certificates be issued.
- The tunnel has one destination
- The connection your cluster opens to us can only ever be forwarded to your cluster's own ingress controller. It is not a network route into your cluster: there is no message we could send back down it that would reach anything else, because the agent reads the destination from your cluster and never from us.
- Builds stay put
- Source is cloned and images are built by your cluster, on your hardware. Build output is not shipped to us.
What we store, and how
- Secrets are encrypted at rest
- Values inside a project secret are encrypted with AES-256-GCM before they are written to the database, under a key ID that allows rotation without re-encrypting everything. Plaintext exists only in memory and on the TLS connection to your agent.
- The threat model is storage
- The goal of that encryption is specific: a database dump or a volume snapshot should not hand someone every customer's credentials. It is not a claim that Anyport staff can never see a decrypted value.
- Secret values are not shown by default
- The console lists secret names. Revealing a value is a separate permission, and it is recorded.
Access control in your organization
- Roles and per-resource permissions
- Admin, editor and viewer, refined per resource. Every delete path checks permission before it does anything.
- Terminal access is its own permission
- A shell into a running container defeats most other restrictions, so it is granted separately. Forwarding a port to your own machine is the same grant and runs the same checks, because it is the same unrestricted access to whatever is listening. You can restrict both to admins, or switch them off for the whole organization — which also kills every session already open.
- Audit log
- Every change is recorded with the account that made it. Entries are retained for 30 days.
- Accounts
- Authentication is handled by Auth0. Email verification is required before an account can do anything.
What we don't have
If any of these rules Anyport out for you, it should.
- No compliance certification
- No SOC 2, no ISO 27001, no HIPAA. We are not going to imply otherwise with a badge.
- No third-party audit
- Anyport has not had an external penetration test, and there is no bug bounty programme yet.
- No SLA
- There is no uptime commitment on the console, and none is implied by this page. Your workloads do not depend on it: they are ordinary Kubernetes objects, so they keep serving while our control plane is unreachable.
Reporting a vulnerability
If you have found a security issue, tell us before you tell anyone else and we will work it with you. Email security@anyport.dev, or use the contact form and say it is a security report — either gets read first.
Reporting abuse — content served through an Anyport-published hostname — is a different address: abuse@anyport.dev. We acknowledge those within one business day. Worth knowing before you write: we route to customers' own machines rather than hosting their content, so our remedy is to stop publishing a hostname, not to remove a page. Our acceptable-use policy says what we can and cannot do.