Ephemeral by default
Each workspace is disposable, so you start from a clean, reproducible state and tear it down when you are done.
Deliver
Developer Workspaces
Ephemeral, ready-to-code workspaces on your own infrastructure
Spin up disposable, pre-configured developer workspaces (built on Coder) that run on infrastructure you own and are governed like everything else on the platform. Reach them from the service catalog, with single sign-on and policy applied the moment they start. This is an emerging capability under active development.
- Developer environments governed by the same policy layer as the rest of the platform
- Source code and secrets stay inside your own infrastructure boundary
- No standing footprint after the work is done
The problem
Your development environments live outside the governance boundary. Engineers set up workspaces by hand, authenticate through paths that bypass your identity layer, and leave environments running long after the work is done. There is no catalog link, no policy applied, and no record of who had access to what.
Without IntegraCI
- Dev environments set up by hand, outside any governance
- Source code and secrets accessible through an ungoverned path
- Long-lived environments that outlast the work and retain access
- No catalog connection, no policy, no audit record
With IntegraCI
- Workspaces launched from the service catalog with policy applied at start
- Source and secrets provisioned inside your own infrastructure boundary
- Ephemeral environments that tear down and leave no standing footprint
- Single sign-on routes every workspace through the same identity layer
What you get
Runs on your infrastructure
Workspaces are provisioned on infrastructure you own, keeping source and secrets inside your boundary.
Catalog-native access
You launch and find environments from the same service catalog you use for everything else on the platform.
Governed like the rest
Single sign-on and policy as code apply to every workspace, so developer environments are not an ungoverned side door.
How it works
- 1
Request from catalog
You open the service catalog and request a workspace for the service you want to work on.
- 2
Provision and connect
The platform provisions an ephemeral Coder workspace on your infrastructure and connects you through single sign-on.
- 3
Code, then dispose
You work in a ready-to-code environment and tear it down when finished, leaving no standing footprint.
How it stays governed
The same gates everyone passes, applied here.
Gated by policy
Every workspace is evaluated against policy as code from the moment it is provisioned. The same rules that apply across the rest of the platform cover developer environments, so they cannot become an ungoverned side door that bypasses your controls.
Recorded, tamper-evident
Each workspace creation, connection, and teardown is recorded in a tamper-evident audit trail, giving you a durable record of who accessed which environment and for how long.
Works with your stack
Connect the tools you already run.
Identity providers supply the single sign-on that gates every workspace; source control systems give the catalog the context for which service a workspace belongs to.
- Atlassian
- Gerrit
- Gitea
- GitHub
- GitLab
- Microsoft
- Apple
- Argo Project
- AWS
- Cloudflare
- CNCF
- Coder
- Crunchy Data
- Daytona
- Env0
- Keycloak
- MongoDB
- +13 more
Who it’s for
Where teams reach for it.
Onboarding without manual setup
A new engineer opens the service catalog, requests a workspace for the service they will work on, and gets a pre-configured environment without touching infrastructure by hand.
Feature work with a clean boundary
A team working on a sensitive service runs each piece of work in an ephemeral workspace that disappears when the task is done, so no standing access accumulates between assignments.
Regulated teams keeping source inside the boundary
Teams that cannot let source code or secrets leave their own infrastructure use catalog-linked workspaces provisioned on infrastructure they own, covered by the same policy layer as everything else on the platform.
Questions, answered.
Does IntegraCI replace the workspace engine?
No. IntegraCI governs the workspace engine you are already running. It connects that engine to the service catalog, applies policy as code, and routes authentication through single sign-on. The underlying workspace technology keeps doing what it does.
Where do the workspaces actually run?
On infrastructure you own. IntegraCI provisions them there, so your source code and secrets never leave your boundary or pass through IntegraCI's infrastructure.
How are access and policy rules defined?
Rules are expressed as policy as code, the same mechanism used across the rest of the platform. You define them once and they apply to every workspace from the moment it starts, with no per-team wiring required.
Is this capability production-ready?
Developer Workspaces is an emerging capability under active development. The governance primitives, catalog integration, and single sign-on are in place. Additional depth in the workspace experience is being added.
Put Developer Workspaces on your stack.
Request a demo, or read the docs to see how it fits the tools you already run.