Solana Playground: a browser IDE with a fixed crate whitelist

Writing a Solana program without a local toolchain

Solana Playground, short name SolPg, is described as a tool that lets you quickly develop, deploy and test Solana programs, meaning smart contracts, from a browser. The hosted instance lives at `https://beta.solpg.io`.

The point is to remove the setup step. A local Solana development environment normally means a toolchain, a test validator, a wallet and a way to ship a compiled program. Here the browser is the shell, and the compilation happens in a WebAssembly component that the repository ships as the `wasm/` directory. The topic tags on the repository include `wasm` and `webassembly`, and the primary language is Rust, so the program under development is ordinary Rust that happens to be compiled for the Solana target rather than for the host machine.

The repository layout is the clearest statement of the architecture. There is a `client/` directory for the browser front end, a `server/` directory for the backend, a `wasm/` directory for the WebAssembly pieces, a `vscode/` directory, and `supported-crates.json` and `supported-packages.json` at the top level. A `Makefile` at the root is described as an aggregator for per-area submakes, and it includes `client/Makefile.vercel`, so deployment targets a Vercel style frontend flow as well as containers.

The crate list is a whitelist, and the versions are pinned

The supported crates table in the readme is long and specific, and each entry names a crate and an exact version. `anchor-lang` and `anchor-spl` are at 0.29.0, `borsh` and `borsh-derive` at 0.10.3, `solana-program` at 1.16.24, `spl-token` at 4.0.0, `mpl-token-metadata` at 3.2.3, `pyth-sdk` at 0.8.0, `switchboard-solana` at 0.29.79, `serde` at 1.0.193, `bytemuck` at 1.14.0, and so on.

Two things follow from that list. First, the environment is closed. You cannot add an arbitrary dependency to a program you write in the playground, because the compiled code has to run inside the sandboxed WASM environment with a fixed set of libraries available. The readme says you can open an issue to request more crates, which confirms that the set changes through the project rather than through the user's project file.

Second, the versions are frozen. `solana-program` at 1.16.24 is a specific point in that library's history, and the pinned Anchor version determines which macro set a program is written against. A program that compiles in the playground may not compile against a newer Anchor version on your own machine, and the reverse is equally true.

The two JSON files at the top of the repository, `supported-crates.json` and `supported-packages.json`, are where that whitelist actually lives. They are the files to read before planning a program, rather than the readme table.

Docker Compose profiles decide which parts actually start

The project can be built and run entirely through Docker Compose, and the profiles are the control surface. You copy the example environment file first.

# Copy and customize environment variables
cp .env.example .env

Then you pick a profile. The full development stack runs in watch mode.

docker compose --profile dev up --build

The production profile builds static assets instead.

docker compose --profile prod up --build

And there are narrower options for working on one side of the system at a time.

# Client only
docker compose up client-standalone --build

# Server + DB
docker compose --profile dev up server --build

The client answers on port 3000 and the server on port 8080, as the compose file and the environment file agree, since the ports are published as `${PG_CLIENT_PORT:-3000}:3000` and `${PG_PORT:-8080}:8080`.

Tearing it down is equally declarative, and the difference between the two commands matters because one of them destroys data.

# Stop services
docker compose down

# Stop and remove database volume
docker compose down -v

The second one removes the MongoDB volume, so the saved data goes with it.

A WASM service has to finish building before the client starts

The compose file describes four services and the dependency order between them is the interesting part.

The `wasm` service builds from the `./wasm` context, and both client variants declare `depends_on` the wasm service with the condition `service_completed_successfully`. That is not a health check, it is a build ordering constraint. The WebAssembly artifacts have to exist before the client image is assembled, because the client Dockerfile takes them as an additional build context through `additional_contexts`.

The server depends on `db`, and the database is `mongo:7` with a named volume mounted at `/data/db`. The server receives its database URI from the environment as `PG_DB_URI`, defaulting to `mongodb://db:27017`, and the database name is set separately as `PG_DB_NAME=solpg`.

The remaining environment variables in `.env.example` describe the knobs. `PG_BUILD_CONCURRENCY=16` controls parallel compilation, `PG_PAYLOAD_LIMIT=1048576` sets a payload ceiling, `PG_CLIENT_URLS` lists the allowed client URLs, `PG_SERVER=true` switches the client into server-connected mode, `PG_VERBOSE=false` and `RUST_LOG=error` control logging.

There are also standalone variants. `server-standalone` runs the server without the database, and `client-standalone` runs the client with `HAS_SERVER` set from `PG_SERVER`, defaulting to false. Those exist for splitting the deployment across machines or for running the client alone.

Every container is amd64, and the project says so

The compose file sets `platform: linux/amd64` on the client, server and wasm services, and the readme explains why: Solana and Agave do not ship Linux ARM64 binaries. The consequence for a developer on an Apple Silicon machine is that the stack runs under emulation, and the readme names the ways to do that. Linux runs it natively, macOS works through OrbStack or Docker Desktop, and Windows works through WSL2 or Docker Desktop.

The readme also separates the recommended local setup from the container route. For running the project directly on a host, it points at a client setup guide and a server setup guide inside the repository, and it states the recommended tool versions: `node --version` at v22.20.0 and `yarn --version` at 1.22.22.

node --version
# v22.20.0

yarn --version
# 1.22.22

Those are the two version numbers to match if you go the native route, and they are older than what many machines ship by default, which is worth knowing before you start changing versions around.

One more limitation is stated plainly. The readme notes that Playground is still in beta and everything is subject to change. For a learning tool that is a fair trade, and for a program that will hold value it is a real one, particularly given the pinned crate versions discussed earlier.

Where the hosted service and a self hosted stack differ

There are two ways to use this project, and they are not equivalent.

The hosted instance at `https://beta.solpg.io` gives you a browser IDE with no infrastructure to run. The trade is that your programs, your build environment and your dependency versions are the ones the project publishes, and the readme's beta note applies to that service as much as to the code. The published crate list is the contract you are writing against, and it changes when the project changes it.

Running the Docker Compose stack yourself reverses that. You control the deployed version of the server, the database and the container images, you can change the environment variables including the payload limit and the build concurrency, and the client URL list, which is what makes a self hosted instance usable at your own domain. What you take on is the wasm build stage, the MongoDB instance and the amd64 constraint.

For a team that wants to try Solana program development without touching a Rust toolchain, the hosted instance is the cheap starting point. For a team that will eventually deploy an internal tool, the self hosted route is the one that ends with something they control, and the compose file is the whole deployment description.

The repository also contains a `vscode/` directory, so there is an editor oriented component alongside the browser one. The readme does not describe how it relates to the hosted service, which is exactly the sort of gap you would want to close by reading the source before committing to either path.

Editorial conclusion

Solana Playground suits a developer who wants to write a Solana program and deploy it without installing a Solana toolchain, and it does not suit a team with a custom crate dependency, an ARM64 build host or a requirement for a licence other than the split the project documents. Before adopting it, check `supported-crates.json` for the crate you need, expect every container to run as `linux/amd64`, and read the licence split, since the readme places the public wasm libraries under Apache-2.0 and the rest of the code under GPL-3.0 while the project itself is labelled beta.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. solana-playground/solana-playground on GitHub