# PlayCanvas Editor: Local Setup, Architecture, and Adoption Limits

> PlayCanvas Editor is a browser-based TypeScript frontend for building WebGL, WebGPU, and WebXR applications. It is best suited to PlayCanvas users and frontend contributors who want visual editing or need to develop against a local frontend build.

**playcanvas/editor** — Browser-based visual editor for building WebGL, WebGPU, WebXR apps

- Repository: https://github.com/playcanvas/editor
- Website: https://playcanvas.com
- Stars: 1,364 · Forks: 227
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/playcanvas-editor

## PlayCanvas Editor's Browser Editing Boundary

PlayCanvas Editor addresses the authoring side of browser graphics projects. Its stated purpose is to provide a visual environment for building applications that use WebGL, WebGPU, or WebXR, rather than serving as the rendering engine itself. The README identifies the PlayCanvas Engine as the library that powers the Editor's 3D View and Launch Page. This distinction matters when evaluating the repository: the `src` tree and Vite configuration belong to an editor frontend, while application execution also depends on the engine and the hosted PlayCanvas services around the editor.

The intended users are therefore broader than TypeScript contributors. Scene creators use the editor through `https://playcanvas.com`, while frontend developers clone `playcanvas/editor` to modify or debug that interface. The repository's package metadata describes it as “The PlayCanvas Editor Frontend.” It is not presented as a command-line scene compiler, a self-contained desktop editor, or a backend implementation.

The project also documents a built-in Model Context Protocol integration through `playcanvas/editor-mcp-server`. According to the README, this lets AI assistants inspect and modify projects through an open Editor session. That feature expands the possible interaction model, but the available repository documentation does not describe its setup, permissions, or supported operations in enough detail to assess those boundaries here.

## Frontend Stack Behind the PlayCanvas Editor

The repository layout points to a TypeScript frontend assembled with Vite. Relevant top-level files include `src`, `static`, `sass`, `vite.config.mjs`, `tsconfig.json`, and `types.d.ts`. The `package.json` declares `"type": "module"`, and its build script invokes Vite after setting `NODE_ENV=production`. The development command combines an incremental Vite build with the preview server through `concurrently`.

The editor interface is based on PCUI, a PlayCanvas front-end component library. PCUI-Graph supplies node-based graph rendering, while Observer provides data binding and history. The PlayCanvas Engine handles the 3D View and Launch Page. These are separate responsibilities: PCUI controls interface composition, Observer manages bound state and change history, PCUI-Graph renders graph interfaces, and the engine presents the graphics-related surfaces.

The project includes a Vite-based development flow rather than a static checkout. `npm run dev` watches the frontend and starts a preview server. The repository documentation does not expose an API port as part of ordinary end-user setup, but it does state that a development frontend is served from `http://localhost:3487`. The hosted editor remains the outer application through which that frontend is loaded.

## Running the Editor Frontend on Port 3487

Local development requires Node.js 18 or later. Clone the repository and install its dependencies before starting the development build. The following commands are copied from the README:

```bash
git clone https://github.com/playcanvas/editor.git
cd editor
```

The clone creates the `editor` directory and changes into it. Install the dependency graph recorded by the project:

```bash
npm install
```

Start the Vite build-and-preview process:

```bash
npm run dev
```

At this point, the development command is intended to serve the frontend from `http://localhost:3487`. That command does not replace the hosted editor. To use it, open an existing scene in the hosted editor and add `use_local_frontend` to the URL:

```text
https://playcanvas.com/editor/scene/<YOUR_SCENE_ID>?use_local_frontend
```

Replace `<YOUR_SCENE_ID>` with the identifier from an existing scene. According to the README, this makes the hosted editor load the frontend from `http://localhost:3487` instead of the production frontend. The same query parameter is supported in the code editor and launch page. A local frontend without a reachable hosted scene, account context, or development server will not reproduce the documented complete workflow.

## Library Links and Integration Test Constraints

Frontend contributors can link local source builds of the supporting libraries into the editor. The README recommends `npm link` for integration work with the PlayCanvas Engine, Observer, PCUI, and PCUI-Graph. First, the library repository is linked globally:

```bash
cd <library>
npm link
```

The editor then links against that global entry:

```bash
cd editor
npm link <library>
```

This changes the dependency source used during integration work. It does not provide a supported command for choosing a stable engine release or pinning several local libraries together, so the linked versions and compatibility remain developer responsibilities.

The end-to-end test suite has heavier prerequisites. It uses Playwright and requires Docker. A `.env` file must be based on `.env.template` and includes authentication and host settings. The documented keys are `PC_HOST`, `PC_LOGIN_HOST`, `PC_LAUNCH_HOST`, `PC_LOCAL_FRONTEND`, `PC_COOKIE_NAME`, and `PC_COOKIE_VALUE`. The account must already exist. Running the suite starts the configured Docker Compose services, while shutdown uses `docker compose down --remove-orphans`. The compose file builds the test image first and then the editor image, mounts authentication state and test results, and sets `PC_LOCAL_FRONTEND=true`. This is not a lightweight unit-test path.

## PlayCanvas Editor Versus a Code-First Engine Workflow

The clearest alternative is a code-first workflow that keeps application authoring in developer-managed source and runtime code, without the hosted visual editor. The difference is where authoring state and interaction live: PlayCanvas Editor adds a hosted visual frontend, account context, scene workflow, node-based graph interface, and a separate local-frontend development path. A code-first engine workflow instead keeps application construction in developer-managed source and runtime code.

This repository does not document migration, synchronization, export, or round-trip behavior between editor-created scenes and a fully code-owned project. The README therefore does not support a claim that a project can be moved cleanly into or out of the visual editor. It also does not describe a standalone editor backend in this repository. Adopters who require complete source control over every editor service should confirm that boundary before depending on the hosted workflow.

PlayCanvas Editor is the more natural choice for creators who want visual scene and graph interactions. The code-first engine approach is the better fit when a team defines scenes and application structure entirely in code and does not need the editor's hosted interface. For teams modifying this repository, the relevant comparison is between using the production frontend and running the documented local build, not between two interchangeable open source visual editors.

## Release Activity, MIT Licensing, and Upgrade Work

The repository is not archived, and its last push was on 2026-10-15. Recent releases include `v2.34.2` on 2026-10-15, `v2.34.1` on 2026-10-15, and `v2.34.0` on 2026-10-07. The release cadence and recent push show current repository activity, although the documentation does not define a long-term support window or compatibility policy for hosted services.

The package metadata and repository identify the license as MIT. That is favorable for organizations reviewing reuse of the frontend source, but license review should cover the exact distribution being used, including bundled dependencies and separately hosted components. This article does not provide legal advice.

Upgrade effort is visible in the tooling. `package-lock.json` supports a reproducible `npm ci` path, which the Dockerfile uses in its install stage, while the README's contributor setup uses `npm install`. Container image updates involve both the prebuilt test image and the local editor image. The compose file uses `ghcr.io/playcanvas/editor/test:latest`, so its tag follows a floating registry name rather than an immutable release identifier. Production builders should account for that when reproducing the Docker setup.

## Conclusion

PlayCanvas Editor fits browser-based 3D application creators who accept the hosted PlayCanvas environment and frontend contributors working on the editor itself. It is a poor fit for developers requiring a fully standalone open source editor server or expecting repository cloning to produce a standalone backend. Before adoption, verify that the PlayCanvas accounts and hosted services required by your workflow are acceptable, confirm that `https://playcanvas.com/editor/scene/<YOUR_SCENE_ID>?use_local_frontend` connects to a local frontend on port 3487, and review the MIT licensing and release state relevant to your deployment.

## FAQ

### How do I run the PlayCanvas Editor locally?

Install Node.js 18 or later, clone the repository, run `npm install`, and start the frontend with `npm run dev`. The README says the local frontend is then loaded from `http://localhost:3487` through the hosted editor URL using `use_local_frontend`.

### Does PlayCanvas Editor include the rendering engine?

The repository describes itself as the Editor Frontend and identifies the PlayCanvas Engine as a separate library powering the 3D View and Launch Page. The repository can link a local engine checkout for integration testing through `npm link`.

### What do I need to run the PlayCanvas Editor test suite?

The end-to-end suite uses Playwright, Docker, and a `.env` file based on `.env.template`. It also requires authentication values and an existing PlayCanvas account. The documented execution path is `docker compose up`.

## Sources

- [License: MIT](https://github.com/playcanvas/editor/blob/main/LICENSE)
- [playcanvas/editor on GitHub](https://github.com/playcanvas/editor)
- [Project website](https://playcanvas.com)
- [README](https://github.com/playcanvas/editor/blob/main/README.md)
- [Releases](https://github.com/playcanvas/editor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/playcanvas-editor