Remix Project: The Browser-Based Solidity IDE and Its Self-Hosted Build

What Remix IDE solves, and who actually needs it

Writing a Solidity contract normally means installing a compiler, wiring a build tool, and picking a chain to deploy to before you can see whether the code even compiles. Remix IDE removes that setup step. The README describes it as "a comprehensive smart contract development tool" used "for the entire journey of contract development by users of any knowledge level", and it runs in the browser at remix.ethereum.org. The audience is therefore split: people learning Solidity who want a compiler and a deploy button without touching a terminal, and experienced developers who want a quick place to paste a contract, inspect the compiled bytecode, and step through a failing transaction.

The repository is more than the IDE. It is a monorepo containing the IDE itself, a plugin engine, and a set of libraries that the README says are "essential for Remix IDE's native plugins". If you only want to write contracts, you never touch those parts. If you want to extend the IDE or embed its compiler behaviour somewhere else, the libraries under libs/ are the actual product and the IDE is the reference consumer.

One constraint is stated plainly and is easy to miss: the README lists supported browsers as Firefox v100.0.1 and Chrome v101.0.4951.64, and says there is "No support for Remix's use on tablets or smartphones or telephones". This is a desktop tool. Anyone planning to demo contract deployment from a phone is planning something the project does not support.

How the monorepo is put together

The build is orchestrated by Nx. package.json defines the workspace as "Remix Project Monorepo", and the scripts route almost everything through Nx targets: serve, build, test and lint all resolve to nx commands. The root package.json also carries a defaultVersion key pointing at soljson-v0.8.34+commit.80d5c536.js, which is the Solidity compiler build the project pins as its default.

The data flow for a contract is the familiar one. Source in the editor goes to a Solidity compiler (solc, either the pinned default or another version fetched at runtime), which returns ABI and bytecode. The IDE then hands deployment to an injected provider: a browser wallet, a local node, or one of the built-in virtual machines. Debugging works on the transaction level, which is where Remix IDE has historically been strongest.

Nx Cloud appears in the build story. The README states that nx.json "uses the Nx Cloud runner and reads the token from the NX_CLOUD_ACCESS_TOKEN environment variable", and that CircleCI jobs use --cloud when the token is present while forked pull requests fall back to local-only caching. This matters if you plan to contribute: without the token your builds still work, but you will not reproduce the caching behaviour the project's own CI sees. The README suggests verifying this locally by running the same target twice and checking for the message "Nx read the output from the cache".

The Dockerfile is deliberately thin. It starts from nginx:alpine, copies a directory named temp_publish_docker into /usr/share/nginx/html/, and exposes port 80. The container serves static files. It does not compile anything at runtime.

Installing Remix IDE locally and compiling a first contract

The fastest path is Docker, because it skips the Node toolchain entirely. The README gives two image tags: latest for the master branch and remix_live for the latest stable release. Both map container port 80 to host port 8080.

docker pull remixproject/remix-ide:remix_live
docker run -p 8080:80 remixproject/remix-ide:remix_live

After that, opening http://localhost:8080 should show the IDE. The docker-compose route avoids pulling manually and also publishes port 65520, which is the port the remixd daemon uses.

docker-compose pull
docker-compose up -d

The compose file sets restart: always and maps 8080:80 plus 65520:65520, so the IDE comes back after a reboot without intervention.

Building from source is heavier and the README is explicit about the toolchain. Node is pinned to ^20.0.0 and npm to ^6.14.15 in the engines block, and Nx CLI must be installed globally before the workspace commands will run.

yarn global add nx
git clone https://github.com/remix-project-org/remix-project.git
cd remix-project
yarn install
yarn run build:libs
yarn build
yarn serve

The order matters: build:libs runs before the main build because the IDE consumes the libraries. The serve script is worth reading in package.json, since it passes --max-old-space-size=8192 to Node and --memoryLimit=6144 to Nx. That is a large memory budget for a frontend build, and it is a reasonable signal that a small CI runner will struggle. For a production bundle, the README points to yarn run build:production, with output in remix-project/dist/apps/remix-ide, served by yarn run serve:production.

If the build fails, the troubleshooting section asks you to check node --version, npm --version and nvm --version, and notes that Debian-based systems may need apt-get install build-essential followed by npm rebuild.

Offline use and the compiler-version trade-off

The README describes an offline path: the gh-pages branch of the remix-live repository "always has the latest stable build of Remix" as a ZIP file containing the entire build. Downloading it gives you a working IDE with no network dependency at run time.

The catch is stated in the same paragraph. The offline ZIP "contains the latest supported version of Solidity available at the time of the packaging", and "Other compiler versions can be used online only." If your contract must be compiled with a specific solc version that is not the one bundled at packaging time, the offline build cannot do it. That is a real limitation for anyone working against a pinned compiler for reproducibility, and it is the kind of constraint that only shows up after you have committed to an air-gapped setup.

The self-hosted Docker image has a related property: it serves a prebuilt bundle, so upgrading means pulling a new tag rather than rebuilding. That is convenient, but it also means the compiler versions available to you are whatever shipped in that image.

Where Remix IDE is the wrong tool

The README documents unit testing as nx test <project-name>, for example nx test remix-analyzer. That is testing the Remix codebase itself, not testing your contracts. There is no documented headless command for running a Solidity test suite and returning a pass or fail exit code, which is the shape a CI pipeline needs.

Browser testing is the other gap. The README says the ballot test suite "requires running ganache locally" and the remixd suite "requires running remixd locally". Those are external services you have to start yourself before the suite means anything. A pipeline that assumes yarn test covers everything will be surprised.

So the boundary is clear. If your workflow depends on running contract tests on every push, on generating gas reports, or on deterministic scripted deployments across several networks, Remix IDE is not built for that and the repository does not claim otherwise. It is an interactive environment. The moment you want the same result twice without a human clicking, you have left its design centre.

There is also the browser support line to take seriously. Pinning to Firefox v100.0.1 and Chrome v101.0.4951.64 as the supported versions means a locked-down corporate browser policy could put you outside what the project tests against.

Foundry and Hardhat: the difference is where the work happens

Foundry and Hardhat are the obvious alternatives, and the distinction is not feature count but where the loop runs.

Hardhat is a JavaScript and TypeScript task runner. You write deployment and test scripts, run them with a CLI, and get machine-readable output. It is designed to be invoked by CI from the first commit. Remix IDE, by contrast, is designed to be invoked by a person.

Foundry takes the opposite stance on language: tests are written in Solidity and run by a compiled binary, with no JavaScript in the loop. That makes the test suite look like the contracts it tests, which some teams prefer, and it produces fast, scriptable runs. Neither Foundry nor Hardhat ships a browser debugger comparable to stepping through a transaction in Remix IDE.

The practical arrangement most teams land on is not choosing. Use Remix IDE to write and inspect a contract and to debug a transaction that failed on a testnet, then move the finished code into a Foundry or Hardhat project where the repeatable parts live. The remixd daemon exists precisely for that handoff: the compose file's 65520 port is the socket Remix IDE uses to reach a local filesystem, so the browser editor and your local project can share the same files.

Licence, maintenance and upgrade cost

The repository is licensed Apache-2.0 according to the repository metadata and the LICENSE file. There is a discrepancy worth flagging: package.json declares "license": "MIT" for the root workspace package. If you are vendoring or redistributing any part of this monorepo, read LICENSE and the individual package manifests rather than trusting a single field, and get your own legal review. Nothing here is legal advice.

On maintenance, the last push was on 2026-09-23 and the most recent release listed is v2.6.2 on 2026-09-22, with v2.6.0 on 2026-09-18 and v2.5.7 on 2026-09-04. The repository is not archived. That is a steady release cadence over the period shown.

Upgrade cost depends on which surface you use. The online IDE at remix.ethereum.org upgrades itself and you pay nothing except the risk of a behaviour change landing mid-project. The Docker image is a tag pull, so pin a tag rather than tracking latest if you need stability. Building from source is the expensive path: the Node engine is pinned to ^20.0.0, Nx CLI must be global, and the serve script asks for 8 GB of Node heap, so a contributor machine that is short on memory will feel it. The root package.json version reads 2.6.0-dev while the latest release is v2.6.2, which is normal for a development branch but means the version string in a source checkout will not match the released tag.

Editorial conclusion

Adopt Remix IDE when you want a Solidity compiler, deployer and transaction debugger in a browser tab with no local toolchain, or when you need an air-gapped build from the remix-live ZIP or the remixproject/remix-ide Docker image. Do not adopt it as a CI test runner or as a replacement for a scripted framework; the repository documents no headless contract test command, and its own browser suite depends on ganache and remixd running locally. Before committing to a self-hosted deployment, verify that your Node version satisfies the engines field in package.json, that port 8080 is free, and that the remix_live image tag actually resolves on Docker Hub, since the README names it without a version.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. remix-project-org/remix-project on GitHub