What a Kiste can reach, what it cannot, and how traffic reaches a Kiste at all.
Last updated: 6 October 2026
Outbound: what a Kiste may reach
A Kiste has outbound access to the public IPv4 Internet: package managers, Git hosts, APIs and anything else development work needs. The following is blocked for every Kiste:
| Blocked | Why |
|---|---|
| Other Kisten, including your own | No Kiste can be used to reach or probe another. Use SSH through kiste.run or a published port to connect Kisten on purpose. |
| The compute server itself and its services | A guest has no path to the host beyond its virtual devices. |
| The Kiste control plane on internal paths | Kisten reach the control plane only like any other Internet client. |
| Private address ranges (home, office and data-centre networks) | A Kiste cannot reach the network the server sits in. |
| Link-local and cloud metadata addresses | There is no metadata service to steal credentials from. |
| Outgoing mail on TCP port 25 | Direct mail delivery from Kisten is blocked so a Kiste cannot be used to send spam. Mail submission to your provider on ports 587 and 465 works. |
| Spoofed sender addresses | A Kiste can send only from its own address. |
| More than 50 new connections a second (after a burst of 500) | Builds and package managers never get near this. Port scans and floods do, and are cut off. |
| IPv6 | Disabled inside Kisten so no rule above can be bypassed over a second protocol. |
These rules are enforced on the compute server, outside the Kiste. Nothing you do as root inside a Kiste changes them.
Sending mail from a Kiste
Configure your application to submit mail through your mail provider's submission port (587 with STARTTLS or 465 with TLS) and its credentials. Port 25 stays closed. We do not lift that block for single accounts.
Inbound: how traffic reaches a Kiste
The compute server has no open port on the Internet. It opens an encrypted outbound tunnel to Cloudflare, and every request reaches it through that tunnel after kiste.run has authenticated it. A request without kiste.run's authentication is rejected by the server.
| You use | Path |
|---|---|
kiste ssh, scp, editors over SSH | SSH inside a WebSocket to kiste.run, which passes it to your Kiste's SSH server. The CLI pins the Kiste's host key. Kisten have no public SSH address. |
| The browser desktop | Signalling through kiste.run. The video stream goes over WebRTC and is encrypted end to end between your browser and the server. If a direct connection is not possible, a Cloudflare TURN relay forwards the encrypted packets without being able to read them. |
| The web terminal | A WebSocket through kiste.run, bound to your session. |
A published port (kiste stream) | https://<label>.kiste.stream, through kiste.run's edge to that one port of that one Kiste. The label is a long random value. Unpublishing closes open connections. |
Everything else that listens inside your Kiste is unreachable from the Internet unless you publish it.
Published services
How publishing works: Kiste Stream.
A published port is reachable by anyone who has its address. Treat the address like a
password, and add your own authentication when the service is not meant to be public. Published
services run under the separate domain kiste.stream, so they cannot read kiste.run's cookies or
storage. Until kiste.stream is on the Public Suffix List, the edge also keeps services from
setting cookies for each other.
Rate limits
Every API route has per-address and per-account limits, and published services have their own
budget, so that one tenant cannot degrade the platform for others. A refused request gets
429 with a Retry-After header. The numbers are on Limits.