Features

Web IDE — VS Code in the browser, on your live site

Open a full VS Code editor straight from the dashboard and work on your site's real files, with git built in and the whole editor inside the same CageFS-isolated jail as your SFTP access — nothing to install locally, and no separate copy to drift out of date. It edits the LIVE site: a file you save is on the public internet the moment it is written, though a static file may keep serving from the CDN cache for up to four hours.

Start free See pricing

VS CodeFull editor, in the browser
700,000+sites hosted worldwide
2Ways in: Web editor and SFTP
99.99%Uptime assurance

The editor you already know, pointed at the live filesystem

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.

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.

The editor you already know

The file tree, search across the whole site, multi-file editing and the keybindings you already know — the editor you use locally, running against the server instead of your laptop.

The live files, not a copy

You are editing the site itself. There is no staging copy in between and nothing to sync afterwards — which is what makes it fast, and what makes it worth reading twice before you save. Static files may keep serving from the CDN cache for up to four hours.

Git built in

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.

wp-cli where the code is

For WordPress work the command line matters as much as the editor. Both are in the same place.

wp-cli runs against your site from the panel terminal. 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.

wp-cli from the panel terminal
One-click WP admin login when the fix belongs in the admin rather than the code
Plugin and theme install, activate, update and remove from the panel
Access, error and PHP logs available alongside the editor
phpMyAdmin and Adminer embedded and SSO'd for direct database work
FileGator file manager embedded and SSO'd for bulk file operations

Isolated at the kernel, audited at the edge

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.

CageFS filesystem isolation

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 SFTP sessions run in.

LVE resource isolation

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.

Least-privilege credentials

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.

Audit-logged access

Access is audit-logged with actor, action and target — the same discipline applied to every privileged action on the platform.

Shape the runtime, not just the code

An editor is only half of a development environment. The other half is the stack underneath it, and that is configurable per site.

Per-site PHP version selector, so a legacy plugin and a modern build can live on the same account
Editable PHP settings — memory_limit, max_execution_time, upload and post size and the rest — within your entitlement
Per-site PHP extensions toggled on or off: imagick, gd, redis, memcached, bcmath, intl, soap and more
Per-site LSAPI PHP workers, bounded by LVE entry-processes and configurable within your tier
Per-site cron management for both WP-cron and real cron, plus per-site environment variables
Redis or Memcached object cache per site, served by LiteSpeed Enterprise with HTTP/3 on
MariaDB per site with multiple databases and users, and a remote access toggle when you need an external client

From edit to live, safely

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.

AI in the editor, and any AI outside it

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 in the dashboard, 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.

FAQ

What exactly is the Web IDE?

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, with git, editing that site's real files on the server — the live ones, with no staging copy in between. Nothing is installed locally and there is no separate copy to keep in sync.

Do I still get SFTP?

Yes. The web editor is one way in, alongside SFTP — and, on plans that include SSH, a jailed shell. All of them land in the same CageFS-isolated view of your files, so you can use the editor for one task and your own client for the next. Footprint-Free plans get SFTP rather than a shell.

Can other tenants see my files through it?

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 malware scanning, the proactive WAF and that isolation are included on every account instead of being sold as an option.

Can I give a developer access to just one of my sites?

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.

Is the web editor available on every plan?

It isn't a plan feature, so the answer doesn't depend on which plan you buy — it depends on where the site runs. The editor opens on sites we host on our own fleet, because it runs inside that site's own isolated container on our servers. If you've chosen to deploy a site somewhere else — another hosting platform, Cloudflare Pages, Netlify, GitHub Pages or your own server — you edit that site where it runs. VPS and cloud products don't include it either: there's no managed container for it to open onto.

Does the AI assistance in the editor cost extra?

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. It is in the dashboard today; inside the editor it is in active development and not yet available. Separately, our MCP server lets external AI tools such as Claude Code or Cursor drive your hosting directly, scoped by your API permissions.

Should I edit production directly?

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.

How do I try it?

Start a card-free 14-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.

Open the editor, not a support ticket

Full VS Code in the browser. Start with a card-free 14-day trial — no payment details, up to 5 sites on Footprint-Free.

Start free