Everyone's own machine
- Onboarding is an afternoon aligning versions.
A cloud workspace that already hangs off the pipeline
A cloud IDE after which you still hunt for Actions and a hoster is just delayed setup. The workspace here is the same box that later deploys.
- VS Code, JetBrains, RDP, VNC — not only the browser tab
- iOS stays on macOS in the pipeline. The Ubuntu box is the shared Linux base.
Laptop zoo or the same box
Workspace from the project
- Already configured. Same CI afterwards.
Work locally or in the cloud?
Entirely your call—we give you the ideal setup for both paths.
Local
Setup app
- Git & repos
- Flutter SDK
- Node.js
- Docker
The setup app detects tools and starts everything with one click.
Cloud
Remote workspace
- Ubuntu VM
- VS Code in browser
- From anywhere
Ready-made dev environment—no local setup required.
A cloud development environment is worth it when onboarding lasts longer than the first commit. It is worth more when that same environment later builds and ships — otherwise you only moved the laptop into the browser.
Local setups versus workspaces from the platform
This shows the work that development environments create and how the Application Platform deals with it.
| Task |
With the Application Platform
|
Set up manually
|
|---|---|---|
| Onboarding new developers | Fully covered: Start a workspace and go, with tooling and dependencies already in place | Not offered: A setup guide in the wiki that is rarely current |
| A consistent environment | Fully covered: Everyone works on the same base regardless of their own operating system | Not offered: Windows, macOS and Linux side by side with diverging versions |
| Ways to connect | Fully covered: VS Code in the browser, JetBrains, RDP and VNC over stable gateway URLs | Partly covered: Local only, with remote access something you build yourself |
| macOS for iOS builds | Partly covered: Pipeline builds on the platform’s macOS machines. Interactive macOS workspaces come next | Partly covered: A Mac per iOS developer, or a shared box someone has to maintain |
| Separating client projects | Fully covered: A dedicated environment and dedicated credentials per project | Not offered: Everything on one machine, with dependencies and logins bleeding together |
| Compute for heavy builds | Fully covered: The workspace runs on a cloud VM instead of your notebook | Not offered: Build times depend on whatever hardware each person has |
| Looking into databases | Fully covered: phpMyAdmin is available for database access | Partly covered: A local client, a VPN or an SSH tunnel depending on the environment |
| Running AI coding agents | Fully covered: Agents keep working in the cloud workspace after you close the lid | Not offered: Runs locally and stops the moment the machine sleeps |
| Losing or changing a device | Fully covered: Your work lives in the workspace and the repository, not on the endpoint | Not offered: Reinstall and restore everything on the replacement machine |
| Permissions on environments | Fully covered: Roles and project membership decide who may open which environment | Not offered: Effectively anyone with access to the machine |
Green means fully covered, amber partly, grey not offered. Local development stays available through the Setup app.
As of 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.
What a cloud IDE is not
- Not a device replacement Heavy native iPhone work stays on a Mac. The workspace VM is the shared Linux base, not the App Store machine.
Pricing model
Workspaces run as part of the platform, not as a second IDE subscription next to GitHub.
Getting to a cloud development environment
Four steps from project to a running workspace.
-
Create or join a project
Workspaces belong to a project, so repository access, structure and credentials are already there.
-
Start a workspace
Pick Ubuntu as the workspace OS (Windows and macOS come next). iOS builds still run in the pipeline on the platform’s macOS machines.
-
Choose how to connect
Use VS Code in the browser, connect your JetBrains IDE, or open a graphical session over RDP or VNC.
-
Build and deploy
Commits go into the same repository as always, and the pipeline handles test, build and deployment.
Frequently asked questions
Do I have to develop entirely in the cloud?
No. You can keep working locally with the Setup app. Many teams use both: local for everyday work, and a cloud workspace for tasks needing a particular environment, such as iOS builds. Either way you start from the same project base.
How do I connect to a workspace?
Through stable gateway URLs that stay the same across restarts. From there you can open VS Code in the browser, attach a JetBrains IDE, or start a graphical session over RDP or VNC. phpMyAdmin is available for databases, so no local client is needed.
Can I build iOS apps without owning a Mac?
Pipeline builds, yes. iOS builds run on the platform's macOS machines without you buying hardware. Interactive macOS workspaces come next – under Workspaces you currently pick Ubuntu. Signing and store uploads use the same pipeline.
How are client projects kept apart?
Each project gets its own environment and credentials, and roles plus project membership decide who can open it. That is the difference from a laptop holding the logins of eight clients. Permission changes are recorded in the audit log.
Can an agent work in a workspace?
Yes, and it is one of the more common reasons to spin up a workspace. An agent working through a longer task keeps going while your notebook is off. Through the MCP server it gets project context, and its output lands as commits in the repository.
Start your first workspace
Register for free, create a project and open a fully configured environment in your browser.