PlayCanvas Engine

Last reviewed Aug 26, 2026 · 842 words

"Self-hosting PlayCanvas" means one specific thing: you own the runtime (the engine, MIT, 16,562 stars, an ordinary npm package) and the build output (static HTML, JavaScript and asset files), and you serve them from any web server you like. It does not mean running the PlayCanvas Editor on your own hardware, because the editor's back end is a cloud service that PlayCanvas operates. If your project depends on the visual scene editor living on your machine, stop here and look at Godot or Phaser. If you are comfortable writing scenes in code, PlayCanvas is the leanest 3D engine you can put on a Caddy box.

The engine is open, the editor is a service

The split trips people up because the two halves share a name. The engine repository on GitHub is the whole renderer, entity-component system, asset loader, physics integration and script runtime, and it has been open source since 2014. The editor's front-end code is public as well, but it talks to playcanvas.com for projects, assets and collaboration, and there is no supported way to stand that back end up yourself. The free editor plan keeps your projects public at last check; private projects are a paid tier.

The hybrid most self-hosters land on is to use the cloud editor for layout when it saves time, export the project as a zip, and serve that zip from their own domain. The exported build has no dependency on PlayCanvas servers. The purist route is to skip the editor entirely and build scenes in code, which the engine supports fully and which keeps the whole project in a Git repository on your Gitea instance.

Deployment is a directory of static files

A code-first project is npm install playcanvas, a bundler such as Vite, and a dist/ folder. The 256 MB of RAM in the listing is what the build step needs; the served game needs nothing server-side at all. Hosting it is the smallest possible Caddy site:

games.example.com {
    root * /srv/games/dist
    encode zstd gzip
    file_server
}

Two details matter more than they look. First, WebGPU is only exposed to pages in a secure context, so the site must be HTTPS even on a LAN if you want the newer renderer; Caddy handles the certificate. Second, the asset payload dominates load time, not the engine. Use GLB models with Draco or meshopt compression and Basis-compressed textures, and let Caddy pre-compress. The engine itself is well under a megabyte minified, which is the number that makes it attractive for the web in the first place.

Where it beats Three.js and Godot in the browser

Three.js is a rendering library. You write the game loop, the scene organisation, the asset registry and the physics glue yourself, or pull in five more libraries. PlayCanvas ships those as one coherent engine: entities with components, a script system with lifecycle hooks, an asset registry that handles loading and reference counting, ammo.js physics, a lightmapper and a particle system. For a small team that wants a game rather than a tech demo, that is weeks of plumbing already done.

Godot 4 exports to the web, but its export is a multi-megabyte WebAssembly runtime that also needs cross-origin isolation headers to enable threads, which complicates hosting and makes first load noticeably slower on phones. PlayCanvas was designed for the browser from the start and shows it: fast startup, WebGL 2 everywhere with WebGPU where available, and 2D support that is good enough for UI-heavy games. The rest of the game engines category covers the native-first options.

What you give up

The community is a fraction of Unity's or Godot's, so answers to obscure questions come from the forum and the engine source rather than a thousand tutorials. Without the cloud editor you are laying out scenes in code, which is fine for procedural or data-driven games and tedious for hand-placed levels. There are no native builds: shipping to desktop or mobile means wrapping the web build in Electron or Capacitor. And parts of the documentation assume you are in the editor, so code-first users read the API reference more than the guides. For 2D-only projects, Phaser has the bigger ecosystem and no editor question to resolve.

What I'd do

Start a Vite project with the playcanvas package, commit it to a self-hosted forge, and deploy dist/ to a Caddy site over HTTPS. Use the cloud editor as a layout tool if it helps, but keep the build reproducible without it so the project never depends on a service you do not control. Compress assets before worrying about anything else. If the game is 3D and browser-first, this is the engine I would pick over Three.js; if it needs a native desktop release or a visual editor on your own hardware, take Godot and accept the heavier web export.