# Cloud workspaces · Neural Inverse Govern > Workspaces built from versioned templates and environments, with egress enforced on the compute host, secrets injected as the person who starts them, and terminals and SSH that never open an inbound port. Source: https://neuralinverse.com/govern/workspaces/ --- ![](/photos/bench.jpg) [Neural Inverse Govern / Cloud workspaces](https://neuralinverse.com/govern/) # Development workspaces that start from what you approved and stay inside your policy. Workspaces built from versioned templates and environments, with egress enforced on the compute host, secrets injected as the person who starts them, and terminals and SSH that never open an inbound port. Built from Versioned templates and environments Runtime Linux containers or Firecracker microVMs Network None, trusted, custom or full Access Terminal and SSH through a relay Compute Hosted, your runners, or your AWS or Azure account Overview A cloud workspace is a development machine Govern builds from a template your administrators approved, inside a project. An environment adds where it runs, its size, its network access, a setup script, variables and vault references, and who may use it. An agent inside the workspace registers with a signed token that is revoked when the workspace stops, serves terminals and SSH through Govern's relay, and hands git and vault credentials to the person's own user without exposing its token. [What it does ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started) What it does ## What cloud workspaces provide. Only what runs today. Partial and planned parts are listed at the end of the page. - **Workspace templates:** A versioned catalogue of Terraform templates with per-template permissions. Versions are activated or archived, and a deprecated template starts no new workspace. - **Workspaces in projects:** Create a workspace in a project from a template, start, stop and rebuild it through the provisioner queue, and list a project's workspaces. Each workspace is checked on its own: use, read, write, secrets and manage. - **Cloud environments:** Named environments fix the compute source, size, template, network access, setup script, variables and vault references. Access is everyone, administrators only, or people granted use; a status computed on the server says whether sessions can start. - **Network access:** None, a trusted list of package registries and source hosts, your own domains, or full access. Proxied access goes through an egress proxy that refuses IP literals, private and metadata addresses, DNS rebinding and mismatched TLS server names. - **Secrets as the person:** Vault references are resolved when a workspace starts, with the permissions of the person starting it, and delivered through the agent. Variables or setup scripts that look like credentials are refused. - **Workspace agent:** Registers with a signed, revocable per-workspace token, fetches its manifest and environment, runs startup scripts, checks app health and ships its stats and logs. A workspace whose agent does not connect is reported failed with the reason. - **Per-person users:** Terminals and SSH never run as root. Each person works as their own Linux user, named by the server; only the owner gets sudo, and only when the template allows it. - **Browser terminal and SSH:** Through Govern's relay: the agent dials out and listens on no port. SSH authenticates with the member's own keys against a pinned host key; port forwarding reaches loopback only, and sftp and agent forwarding are refused. - **Sessions re-checked:** Open terminal and SSH streams are checked every minute and closed when the person's session ends, they leave the organisation or lose the workspace. - **Git credentials:** A credential helper inside the workspace asks the agent for per-host git tokens. The workspace's own token never leaves the agent process. - **Build and agent logs:** Read and stream each build's provisioner log and the agent's log from the console or the CLI. - **Firecracker microVMs:** On hosts with KVM, workspaces run in Firecracker microVMs with a read-only template root, a persistent home disk and no inbound network; hosts without KVM run containers. - **Your own runners:** Once an Owner or Admin allows it, environments can run on the account's own provisioner runners instead of hosted workers. Jobs for one placement never go to another. - **BYOC compute:** Run provisioner and sandbox workers in your own AWS or Azure account. Govern holds no long-lived key, proves least privilege at setup, and workers reach it only over mTLS with short-lived certificates. - **Running hours and quotas:** Running time is metered per account, and a start that would pass the quota is refused. How it works ## How a workspace starts. Every step is decided on the server; the console only shows the result. 1. Choose A member picks an environment or template in a project they belong to. 2. Check Govern checks access to the environment and template, its status and the quota. 3. Resolve Vault references are resolved as that person and the network policy is compiled. 4. Build A provisioner for the right placement builds the workspace with its egress proxy and setup script. 5. Connect The agent registers with its token and serves terminals and SSH through the relay. 6. Record The start, every session and every refusal are in the audit log. Who uses it ## Built for every role that answers for AI. - **Platform engineers:** Publish templates and environments, run provisioner runners and connect cloud accounts. - **Developers:** Start workspaces in their projects and work in them through the browser terminal, SSH or the command line. - **Security teams:** Set network access and who may use each environment, and deny compute sources with policies. - **Administrators:** Decide whether accounts may run environments on their own compute, and set defaults per product. Enforced and recorded ## Enforced on the compute host, not in the client. Network policy, credentials and sessions are decided by Govern and its workers. Enforced - **Egress:** The compiled network policy runs on the compute host. A tool that ignores the proxy settings has no network at all, and a worker that cannot apply a policy refuses the session. - **Widening needs more:** Changing a setup script or widening network access needs manage rights on the environment; narrowing needs only write. - **Tokens:** Stopping, killing or deleting a workspace revokes its agent token, and every agent route needs the current one. - **Placement:** Hosted, own-runner and BYOC jobs go only to their own workers, and workers from another region are refused. Recorded - **Environment changes:** Changed fields and variable names, never values, and the setup script's size. - **Session starts:** Product, compute source, placement, network access and the trusted list version each session ran with. - **Terminal and SSH sessions:** Opened and closed with duration and why they ended, never the command text. Refusals with their reason. Where it runs ## On your compute or ours. [Deployment options](https://neuralinverse.com/deployment/) - **Self-hosted:** Provisioners and workspaces run on infrastructure you operate, as part of your installation. - **Your cloud account:** With the hosted service, workers can run in your AWS or Azure account, in regions inside the service region's jurisdiction. - **Hosted by us:** Hosted workers in the region that serves your account. Get started ## Set it up with the documentation. - [BYOC compute workers](https://neuralinverse.com/docs/deploy/byoc/) - [Workspaces in the Editor](https://neuralinverse.com/docs/editor/workspaces/) - [Deploy and operate](https://neuralinverse.com/docs/deploy/) What's next ## Being built now. These are in development and not part of the product today. - **Automatic start and idle stop:** Start schedules, stopping idle workspaces and deadlines for hung builds. - **Windows and macOS workspaces:** Whole virtual machines with a terminal, SSH and a remote desktop in the browser, under the same environments and audit. - **Snapshots, prebuilds and build cache:** Workspace snapshots and restore points, prebuilt templates and a shared build cache. - **GPU workspaces:** GPU nodes scheduled and allocated to workspaces, with utilisation reporting. - **Sharing and app proxy:** Sharing a workspace with guests, and reaching the apps and ports a workspace serves through Govern. - **Workspace metrics:** CPU, memory and disk series per workspace in Observe. - **More clouds:** BYOC workers in Google Cloud. Related [Sandboxes → Isolated Firecracker sandboxes for agent work, with egress rules, quotas and approved artifacts.](https://neuralinverse.com/govern/sandboxes/)[Identity and access → Single sign-on, provisioning, least-privilege roles, just-in-time access and reviews.](https://neuralinverse.com/govern/identity/)[Audit and evidence → A hash-chained audit log you can verify offline, and evidence toward your frameworks.](https://neuralinverse.com/govern/audit/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)