microStudio: a browser game engine you can also host yourself

Three ways to use it, and the project does not pick for you

microStudio is described as a free, open source game engine online, and it is also a platform to learn and practise programming. Both halves of that description matter, and they pull the design in a specific direction.

The README offers three ways to use microStudio, and each is a genuinely different deployment rather than a variation.

The online service at microstudio.dev is described as the simpler and the preferred way, and it gives access to all the online collaboration features, online publishing and more export features. Notably, you do not even need to create an account, since you can start working as a guest.

The standalone application is the offline route. You download it from the Releases section of the repository, or from itch.io at microstudio.itch.io/microstudio, and it is described as helpful if you plan to use it in an environment without connection to internet.

The third option is to set up your own microStudio server, by cloning the repository and running it for a team or a classroom.

That last option is what distinguishes this from a typical in-browser editor. The code is JavaScript, the licence is MIT with a `LICENSE.txt` at the repository root, and the repository is not archived with the last push on 2026-10-12. The hosted service is a convenience, not a dependency.

The distinction between the three matters for a specific reason: the feature list differs. The online service has the collaboration and the extra export options, and self-hosting gives you control over where the data lives and who can reach it, but a self-hosted instance is your instance to run and secure.

Self-hosting is a clone of two repositories and an npm start

The server installation instructions are short enough to reproduce exactly, and they involve a second repository that is easy to miss.

Install Node JS, then:

git clone https://github.com/pmgl/microstudio.git
cd microstudio
git clone https://github.com/pmgl/microstudio.wiki.git
cd server
npm install
npm start

Then you open a browser on `http://localhost:8080`.

The `microstudio.wiki.git` clone is the detail worth pausing on. The wiki is a separate repository, and the server serves it. That is why it sits inside the project directory rather than in a sibling directory, and it means a self-hosted install has two things to keep in step, not one.

For active development, use `npm run dev` instead of `npm start`.

The repository layout is small and reflects that this is a web application rather than a native engine. There is a `server/` directory holding the Node server, a `static/` directory with the front-end assets, a `templates/` directory, and the `config_local.json` and `config_prod.json` example configurations at the root.

The package metadata is not in the README, but the `server/` directory being separate from a root manifest tells you the server is its own npm project with its own dependencies, and the root `package-lock.json` is not in the listed repository entries, which is consistent with that.

The topic tags name Lua, Microscript, Node.js and Python alongside JavaScript, and the configuration options confirm that the engine is not JavaScript-only.

Hosting options split the run instance from the dev instance

Two configuration options decide what kind of deployment you are running, and they interact.

The `realm` option is either `local` or `production`, and it is the switch that changes the meaning of the domain options. `run_domain` is the run domain if you are running this in production and must include the protocol, for example `https://microstudio.io`. `dev_domain` is the dev domain if you are running in production and must also include the protocol, for example `https://microstudio.dev`.

The separation between the two domains is the split between the public instance where projects are played and the development instance where they are edited. A production deployment therefore needs two hostnames and, behind them, a way of routing a visitor to the right instance depending on whether they are opening the editor or playing a published game.

That routing is exactly what the delegate options exist for. `delegate_relay_service` is set to true if you are running a separate relay server for the microStudio Networking features, and `relay-key` is a secret key to use with the delegated relay service. So the multiplayer networking can run on a separate machine from the main server, and a shared key authenticates the two.

For a classroom this arrangement is the point rather than a complication. A school can run the editor on an internal network and the play instance on a public one, with the relay wherever the network allows, and none of the three has to be the same machine.

For a single-machine install the simpler path is `realm` set to `local` with the default `http://localhost:8080`.

The wiki is a second repository, and it is where teaching content lives

The install instructions clone two repositories, and the second one is not optional. `git clone https://github.com/pmgl/microstudio.wiki.git` puts the wiki inside the project directory, and the server serves it.

That is a small design choice with a large consequence for the intended audience. The project describes itself as a platform to learn and practise programming, and the wiki is where the teaching material lives. A self-hosted instance can replace that material entirely, because `tutorials_root_url` sets a different URL for loading your own set of tutorials.

The option comes with a caveat that says more about how the feature works. If you use `tutorials_root_url`, in the `toc.md` you must specify a complete URL with domain name for each tutorial. So the tutorial index is a document you have to edit by hand, and the entries are absolute URLs rather than relative paths. That is a sensible design for a served site, where the tutorial content can live anywhere, and it also means the index cannot be generated from a directory listing.

Combined with the `default_project_language` option, the result is an instance shaped for a particular class. Set the default language to Python, point `tutorials_root_url` at your own course material, and every new project a student creates starts in the language you are teaching and opens the tutorial sequence you wrote.

That is the strongest argument for self-hosting this project rather than using the hosted service, and it is not mentioned in the feature list.

The `brython_path` option sits in the same area of the configuration. It sets a path to a custom folder for the Brython lib, and Brython is the mechanism behind the Python option, compiling Python to JavaScript to run in the browser. Pointing the server at your own copy of that library is how you would pin or vendor it, which matters for an offline classroom install where the library cannot be fetched at runtime.

What the release history says about the project's pace

The version numbers use a date format, and they tell a story.

The listed releases are 22.11.10 from 2022-11-14, 23.05.25 from 2023-05-25 and 24.01.29 from 2024-01-29. So the naming convention is year, month, day of the release, and the gaps between them were around six months.

Then the last push was on 2026-10-12, which is nearly three years after the newest tag, and the repository is not archived. So the source tree has been worked on for a long stretch without new named releases.

That has a direct consequence for anyone installing the standalone application, since that route is documented as downloading from the Releases section of the repository. The newest tagged build is from January 2024. The code in the repository is much newer than that, but the packaged offline app is not.

The hosted service at microstudio.dev is a different matter, because it runs from the maintained source rather than from a tag.

So the choice between the three routes is partly a choice between release channels. The online service gives you the current code. The self-hosted server gives you the current code, at the cost of running it. The standalone app gives you a dated build that happens to be the one you can run without a server or a network.

The project is MIT licensed with the `LICENSE.txt` file at the repository root, which is a permissive grant with no copyleft obligation and no restriction on running a modified instance for a classroom or a team. That is a licensing observation rather than legal advice, and the `LICENSE.txt` file governs.

Editorial conclusion

microStudio fits a teacher or a team that wants a shared place to build and publish small games and simulations, and who values that the whole thing can be self-hosted on a school server or a laptop with no internet. It does not fit a commercial studio that needs a large asset pipeline, a native build chain or an established engine ecosystem, and it does not fit a user who wants a single-player game without hosting anything at all. Verify first that the language you intend to write in is one of the configured project languages, that the project you plan to publish uses the export targets the online service offers rather than relying on self-hosting for those, and that your deployment has the Node.js version the server expects, since the server is the whole product here.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pmgl/microstudio on GitHub
4. README
5. Releases