How your workspace is kept apart

Handing your team's work to a supplier means handing over conversations, documents and the credentials to systems you run. The question that deserves a real answer is what keeps your instance apart from everybody else's, and where that separation stops. This page answers both, and names the limits as plainly as it names the protections.

Last updated 19 September 2026. This page describes the instances we run for customers.

One customer, one instance

Every customer instance we create is its own project on our host, in its own directory, with its own containers. Your database, your uploaded documents and your container workspaces are directories inside that one folder rather than shared storage, which is why removing the folder removes the database itself. Instances do not share a database, a network or a filesystem with one another, and every container in your stack carries your own subdomain in its name, so no two customers' stacks are ever identified alike.

Your instance listens only on the host's loopback interface. It is reachable through our reverse proxy and by nothing else: it is not published to the internet, and no other container on the machine can route to it. We bind instances that way specifically so that one customer's containers cannot reach another's, having rejected the alternatives for that reason. Each customer is also given an address of their own on that interface, allocated in a way that cannot hand the same one to two customers.

Customers get a subdomain of their own rather than a path under one shared hostname, and that is a security decision rather than a cosmetic one. The browser treats everything under one hostname as a single site when it comes to signing in, so two customers sharing a hostname would sign each other out, and no proxy configuration can undo that. The subdomain you choose is checked strictly before it is used anywhere, and a deletion refuses any location outside the customer area.

Your own database, in your own container

Each customer runs a dedicated database server in a dedicated container reading a dedicated directory. This is not one shared database with a customer column and a filter on every query, which is the arrangement where a single missing clause exposes everybody. Inside your instance, each workspace you create gets its own database as well, with one exception: the workspace an instance starts with keeps its data in the instance's main database alongside the account records.

Your database publishes no port to the host and is addressed only from within your own instance. It runs without database authentication: there is no username or password on it, and what separates it is container networking rather than a credential. We say so plainly because it is a design choice you are entitled to weigh rather than one to discover later.

Where agent code actually runs

Agents get a real computer to work on, which means code your agents run has to be contained. Your stack is never given access to the host's container daemon. Code an agent runs reaches only a daemon confined to your own stack, and that daemon's port is never published to the host or to the internet.

That daemon runs rootless, so a container it starts maps to an unprivileged user on the host rather than to root. The one privileged component in the arrangement is there solely to make that rootless daemon possible. It also relies on hardening we apply to the host itself, including a mandatory access control profile (AppArmor), which is preparation we carry out on our own machines.

Containers that pokrok creates for an environment are hardened the same way every time: every Linux capability is dropped and only a small set for file ownership is restored, privilege escalation is blocked so a process inside cannot gain new privileges, and the temporary filesystem is bounded. Each environment also has an internet switch. Turn it off and that environment is built with no network at all: it reaches nothing and nothing reaches it. Left on, which is the default, it can make outbound requests but accepts no inbound ones.

What is encrypted, and what is not

Every instance is provisioned with its own encryption key, generated freshly and never shared between customers or reused, so material one instance has encrypted cannot be read with another's key.

The product seals a defined list of stored secrets with AES-256-GCM: model provider keys and their extra headers, tool-server environment variables and headers, an environment's secrets, its source-control and file-sharing tokens, connector fields marked secret, the single sign-on client secret, and the notification signing key. On our side, the provider and payment secrets our management service holds are sealed the same way. Passwords are stored with PBKDF2-HMAC-SHA256 over a random salt and compared in constant time; session tokens, inbound API keys and remote-machine tokens are stored only as hashes, never in a form anybody could use.

Everything else in your database is ordinary readable data. Conversation messages, the model's reasoning, tool calls, stored memory and connector activity carry no encryption. Uploaded files, screenshots and voice notes are stored as ordinary files named by a hash of their contents, and those bytes are not encrypted either; what protects them is the permissions on your own data directory. The record describing a file includes any text extracted from a document or transcribed from audio.

So be clear about what encryption at rest buys here. It protects against a lost disk, a stolen backup, or a database dump taken without the matching key. It is not a defence against somebody with administrative access to the host, because the keys have to be readable by the running service. Somebody holding a copy of one customer's database but not its key file would still read conversations and messages, stored memory, retained prompts and completions inside the retention window, account email addresses, password and session hashes, and file records including extracted text and transcripts.

One limit at the model layer deserves naming rather than glossing: your isolation from other customers there rests on our single upstream account with the provider, not on a separate provider account per customer. The provider credential is ours and is never written into a customer's database, so your own database dump or export contains no provider credential.

The website cannot create containers

The public site and the component that can create containers are deliberately separate processes. The site facing the internet has no means of creating or destroying a container itself. It has to ask the provisioning component, which is reachable only on an internal network the outside world cannot route to, and that request is authenticated with a shared secret compared in constant time. The component exposed to the internet is therefore not the component that can build or destroy anything.

Deleting an instance is guarded against mistakes as well as against strangers: an operator has to type the instance's own address to confirm, and deleting its data is a separate, explicitly chosen step. Without that choice the stack is stopped and the data is kept.

Our management service does not read your workspace content. It holds no database credentials for your instance and makes no request to one except through its own provisioner. What it can retrieve is container status, resource usage, disk usage and recent container log output, for troubleshooting.

In transit

Connections to this site and to customer subdomains are served over HTTPS, with TLS terminated at the edge in front of the application servers. We operate that termination ourselves rather than buying it from a content delivery network or a proxy vendor, so no such vendor sits in the path of your requests.

Session cookies are marked Secure, so a browser will not send one over an unencrypted connection to us, and they are also HttpOnly so that no script can read them. When you open an application running inside one of your own environments, your pokrok sign-in cookies are removed from the request before it reaches that application, so code running there never sees your session.

What we do not collect

There is no analytics, telemetry, error reporting or crash reporting anywhere in the product or in the service that runs this website, and that service has no third-party code in it at all. The product's pages are locked by a content security policy to loading scripts, styles, images and connections from your own server only, so no third-party content can appear in the application even by accident, and the one third-party component in its interface is served from our own binary rather than fetched from somebody's network. Nothing in the product reports back to us, and neither the product nor this website contains an update check or a version phone-home. Our reverse proxy's own version check and usage reporting are switched off, and it writes an access log only for failed requests rather than for every page view.

Backups

A backup capability exists and works: a command writes a consistent copy of the database to a path you choose. It is not automatic. Nothing schedules one, and the product's own health check warns when no backup has been taken or the newest is over a week old, which is how a manual process is surfaced rather than hidden. A backup is written inside the instance's own directory as readable text, is not an off-machine copy, and is destroyed along with everything else when an instance is deleted with its data.

The limits of all of this

Every claim above stops somewhere, and you should know where before you decide.

• Workspaces inside one instance are separated more weakly than customers are. Your workspaces share one database server, and the boundary between them is a membership check the application makes on each request rather than a separate machine or a separate credential. They also share one memory store for anything deliberately placed in that shared scope. None of this ever spans customers.
• Granting an environment container access is a large grant. It hands code in that environment the address of your own container daemon, which listens without TLS and without authentication, giving that code full control of every environment in every workspace belonging to you. One of the environments a new workspace starts with has this enabled out of the box, so it is present before anyone turns it on. The uniform hardening described above covers containers pokrok creates, not containers that code inside an environment starts for itself through that access.
• Memory is the only resource ceiling actually enforced per customer. CPU is not capped for your application or your database. Disk is measured and reported rather than enforced by the filesystem. The per-environment memory, processor and process limits an administrator can set are not enforced either: the rootless arrangement that contains agent code does not meter each environment separately, so the only ceiling that actually applies bounds all of your environments together rather than each one.
• All customers' containers run under the same operating-system user on the host. Separation is by container, network and directory, not by a distinct host user per customer.
• An agent can publish a service that needs no sign-in. The default for a newly exposed service requires the viewer to be signed in and a member of the workspace, but an address can deliberately be marked public, and then anybody who knows it can reach it. Applications served that way live at your instance's own address and are not fully isolated from it.
• Traffic inside your stack is unencrypted. Between your application and its database, its container daemon and its screenshot browser, the traffic is plain. None of those ports is published outside your stack.
• Host access defeats the rest. Somebody with root on the host can read the keys and therefore everything they protect. What keeps that closed is operating-system access control and the small number of people who have it.

If a limit above is the one that matters for your organisation, say so before you sign up. Several of them are exactly what an Enterprise arrangement exists to change, including running the whole thing on your own infrastructure.

Related reading: the privacy policy covers what is collected, who processes it and how long it is kept.