Grain and cloud dev environments like Coder

The relationship in one line

A cloud development environment moves the developer's work on a repository to remote infrastructure. Grain starts at a different handoff: the coding agent has built a page, report, dashboard or app, and someone else needs to open it without entering the development environment. Coder is self-hosted on customer infrastructure and positions its workspaces for agents including Claude Code, Codex and Cursor. GitHub Codespaces is a remote development environment tied to GitHub. Neither description makes Grain an editor, and Grain does not replace repository development controls.

What each layer owns

When you need both

Pair the layers when remote development is mandatory but the deliverable has a broader audience. Suppose an operations engineer opens a secured Coder workspace, runs Codex against a repository and asks for a capacity dashboard. Coder owns the remote development context, organization infrastructure and access to the source repository. Grain owns the dashboard artifact, its share URL, Postgres-backed annotations, login boundary and scheduled refresh. The engineer can continue using the remote editor for source changes while managers open only the artifact. The same architecture applies with a GitHub-tied remote development environment: the agent works with the repository there, then publishes selected output instead of giving every reviewer access to the development context.

When you need only one

Use a cloud development environment without Grain when the desired outcome is a controlled development workstation. This fits repository maintenance, interactive debugging, standardized toolchains and work that never needs a separate audience-facing URL. Coder is particularly relevant when your organization wants self-hosted workspaces on its own infrastructure. Use Grain without a cloud development environment when your coding agent already runs locally and its result only needs to be published, shared and retained. A local folder can become a Grain workspace through the CLI. Grain does not provide a remote editor, source-control policy or a general replacement for a development container. The choice turns on who needs access: builders need the development environment; readers need the artifact.

How it fits together

1. Open the development context. Start the repository in the chosen remote environment. Install and authenticate the coding agent under the policies your team already uses. Grain does not change how the remote environment is provisioned.
2. Describe the deliverable. Prompt the agent: Build a capacity dashboard from the included service snapshots. Add a Postgres table for owner notes, login access for the operations group and a daily refresh job. Keep the source adapter separate from the interface. This tells the agent which pieces belong in the artifact.
3. Initialize the artifact workspace. From the project folder, run grain init. It creates the Grain workspace and writes .mcp.json, .codex/config.toml and .cursor/mcp.json. Commit those files only if that matches your repository policy.
4. Build and inspect. The agent writes the page and app files in the remote development environment. Use the environment's editor and terminal for repository-level review. At this point a preview may still be reachable only inside the development context.
5. Publish the selected state. Run grain push, followed by grain checkpoint -m "capacity dashboard ready". The checkpoint identifies a reviewable artifact state rather than exposing the whole development workstation.
6. Create a reader route. Run grain share --password <pw> for password access, grain share --public for an open link, or use invited access. Grain returns a URL shaped like https://<slug>.share.rungrain.com.
7. Continue development separately. Readers comment on the artifact while developers keep the repository and tools in the remote development environment. The agent can read comments, update the workspace files and publish the next checkpoint.

Frequently asked questions