At some point, if you’re building dev tools, automation platforms, or anything with plugins or AI-generated logic, you hit the same wall:
«You need to run user-provided code.»
Not just your code — their code.
And that’s where things get scary 😅
The naive version
At first it looks simple:
result = run(user_code)
return result
And yes… this works.
Until someone uploads:
- an infinite loop
- a memory bomb
- file access
- network abuse
- or just crashes your process
Then you realize:
executing code is easy — executing it safely isn’t.
Why I built GozoLite
I needed something that could:
- run arbitrary code
- not crash my app
- not access my system
- not interfere with other users
- be self-hosted
- be simple to deploy
Most options I found were either:
- too unsafe
- too heavy (full orchestration)
- or external SaaS
So I built a middle ground:
a lightweight self-hosted execution runtime.
The idea is simple
Instead of running code inside your app:
API → GozoLite → isolated container → result
Each execution:
- runs in isolation
- has CPU/memory/time limits
- has no shared filesystem
- dies if it misbehaves
Your app just gets the result.
What surprised me
The hard parts weren’t what I expected.
Not containers.
Not languages.
It was:
- defining execution states
- enforcing limits consistently
- handling failures cleanly
- making results deterministic
Execution systems are basically tiny operating systems 😄
When you actually need this
You probably need an execution runtime if your product:
- runs user scripts
- supports plugins
- executes automation
- runs AI-generated code
- processes arbitrary logic
At that point, execution stops being a feature
and becomes infrastructure.
Final thought
If you’re building something that runs other people’s code:
don’t run it in your app 😅
Isolation isn’t optional — it’s architecture.
If you’re curious about GozoLite or building something similar, happy to share details.
SOCIAL SHARE CARD GENERATOR