We sandbox every build at Doodledapp. Here’s why it matters.
When you compile a smart contract in our visual builder and import a package like OpenZeppelin, that code runs on our servers. NPM packages (the building blocks of most javascript-based software) can execute code during installation.
In web3, attackers have exploited this repeatedly by compromising popular libraries used by hundreds of thousands of developers and draining user funds.
We couldn’t just trust the packages our users import. So we built Doodledapp so that every build runs in its own isolated container, completely cut off from the rest of our infrastructure.
It’s fast enough to feel instant and secure enough to treat every dependency as potentially hostile.
The trade-offs, the architecture decisions, the surprises along the way, it’s all in our latest build-in-public post.
Link: <a href="https://doodledapp.com/feed/we-sandbox-every-build-here-is-what-we-learned" target="_blank" rel="noopener nofollow">https://doodledapp.com/feed/we-sandbox-every-build-here-is-what-we-learned</a>

Rami James

Doodledapp, a visual smart contract builder, runs every user-triggered build inside an isolated container to prevent malicious NPM packages from compromising server infrastructure. The post explains the motivation—supply-chain attacks in web3 have repeatedly drained user funds via compromised libraries—and covers the architecture decisions, trade-offs, and surprises discovered while building the sandboxing system, treating every dependency as potentially hostile.

We sandbox every build. Here is what we learned.