Full VS Code, not a file editor
Syntax highlighting, multi-file search, split panes and the keyboard shortcuts you already have muscle memory for, delivered in the browser by code-server.
Features
Open a full VS Code editor straight from the dashboard and work on your site's real files. Extensions, an integrated terminal, git and wp-cli, all inside the same CageFS-isolated jail as your SSH and SFTP access — nothing to install locally, and no separate copy to drift out of date.
The Web IDE is VS Code running in the browser via code-server, opened from the site you are looking at in the dashboard. It edits that site's actual files — no upload step, no local checkout to keep in sync, and no cut-down web text box pretending to be an editor.
Syntax highlighting, multi-file search, split panes and the keyboard shortcuts you already have muscle memory for, delivered in the browser by code-server.
Install the extensions you work with, so the editor behaves the way your local one does rather than forcing you into a generic environment.
A shell inside the editor, jailed to your site, so you run commands next to the code instead of switching to a separate terminal window.
Stage, commit, branch, diff and push from inside the editor, so work done on the server stays under version control instead of becoming an undocumented hotfix.
For WordPress work the command line matters as much as the editor. Both are in the same place.
wp-cli is available from the panel terminal and over SSH, which means it is available in the Web IDE's integrated terminal too. Search-replace a database, flush a cache, roll a plugin back, bulk-update, export a table or run a one-off script — without leaving the file you were editing.
That closes the usual loop. Read the error in the log, open the file in the editor, change it, run the wp-cli command that proves it, move on. Everything happens against the real site on the real stack, so what you test is what your visitors get.
Browser access to a server is only acceptable if the boundary is real. The Web IDE sits inside exactly the same isolation as every other access route.
Each tenant gets an isolated filesystem view and cannot see other tenants, other sites or sensitive system files. CageFS is designed to contain breaches, and it is the same jail your SSH and SFTP sessions run in.
CPU, RAM, IO, IOPS, processes and entry-processes are capped per site, so a heavy build or a runaway script is throttled inside its own cage rather than dragging neighbours down with it.
Access keys and credentials are managed in the dashboard on a least-privilege basis, so you grant the access a job needs and nothing beyond it.
Access is audit-logged with actor, action and target — the same discipline applied to every privileged action on the platform.
An editor is only half of a development environment. The other half is the stack underneath it, and that is configurable per site.
Editing production directly is sometimes the right call and sometimes a bad idea. The platform supports both paths from the same editor.
Clone the site to staging in one click, open the Web IDE against the staging copy, work there, and push to live when the change is proven. Files and database come across together, on the same stack and blueprint as production, so staging is a real rehearsal rather than an approximation.
If your work belongs in a repository, use git from inside the editor and let git-based deploys carry the change through the build-and-deploy pipeline. Code authored in the browser then follows the same versioned release and rollback path as code written on your laptop.
When a change goes wrong anyway, backups are listed in the panel with one-click restore, and every deploy is a versioned release you can roll back to. The safety net is not a support ticket.
The Web IDE pairs with the in-dashboard AI assistant, and the whole platform is built to be driven by the AI tools you already use.
AI assistance is available inline in the editor, running on your own model through the AI Pack — you bring the model, and the assistant reads and edits files, runs wp-cli and pushes changes. There is no lock-in to an embedded model you did not choose.
Outside the browser, our MCP server lets any MCP-capable client — Claude Code, Cursor, ChatGPT and others — control your hosting and sites in natural language, scoped by your API permissions. The pattern is deliberate: one API and one action catalog, exposed many ways. Build in our editor, build in yours, or let an agent do it, and the same deploy path serves all three.
It is VS Code running in your browser, delivered by code-server and opened from the site's page in the dashboard. You get the full editor — extensions, an integrated terminal and git — editing that site's real files on the server. Nothing is installed locally and there is no separate copy to keep in sync.
Yes. The Web IDE is one of three ways in, alongside a jailed SSH shell and SFTP/FTP. All three land in the same CageFS-isolated view of your files, so you can use the editor for one task and the command line for the next. wp-cli is available from the panel terminal and over SSH.
Each tenant gets an isolated filesystem view under CageFS and cannot see other tenants, other sites or sensitive system files, and LVE caps CPU, RAM, IO, IOPS and processes per site so one cage cannot exhaust the server. CageFS is designed to contain breaches rather than to make risk zero, which is why baseline real-time malware scanning, the proactive WAF and that isolation are included on every account instead of being sold as an option.
Access today is governed by your organisation roles — owner, billing, dev and read-only — and members inherit the permissions of the role they hold in that organisation. Note that the dev role does not carry deploy or push-to-live permission. Optional per-membership resource scoping, such as limiting a member to specific sites, is a planned refinement rather than something available now, and API keys are issued per organisation with granular scopes rather than per individual member.
Entitlements gate what each product line exposes. Mainstream hosting is full self-service, while Footprint-Free hosting is deliberately more standardised and locked down to protect the footprint model, and entitlements also govern PHP workers, disk and extensions. Check the plan you are considering on the pricing page, or ask us before you buy.
Inline AI assistance runs on your own model through the AI Pack, so you bring and pay for the model you want rather than being tied to one we picked. Separately, our MCP server lets external AI tools such as Claude Code or Cursor drive your hosting directly, scoped by your API permissions.
You can, and sometimes that is the fastest correct answer. For anything substantial, clone to staging in one click, open the Web IDE against the copy, and push to live once the change is proven. Git-based deploys and versioned releases with rollback are there when the change belongs in a repository, and backups with one-click restore sit behind everything.
Start a card-free 7-day trial. No payment details are needed; the trial covers Footprint-Free hosting with up to 5 sites, so you can open the editor, work on a real site on the real stack and judge it for yourself.
Full VS Code in the browser, on the platform that hosts 100,000+ PBN sites across every niche. Start with a card-free 7-day trial — no payment details, up to 5 sites on Footprint-Free.
Start free