DEV Community: TotyLabs

I built a self-hosted code execution runtime (because I needed one)

TotyLabs — Wed, 25 Feb 2026 17:09:13 +0000

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.

🧩 The Hidden Layer in Modern Platforms: Secure Code Execution

TotyLabs — Fri, 20 Feb 2026 02:17:54 +0000

Most platforms today expose APIs, workflows, plugins, or automation layers.
But there’s a question that rarely gets asked explicitly:
where does untrusted or dynamic code actually run?
Because at some point, many systems need execution:
user-defined logic
automation scripts
plugin runtimes
AI tool calls
educational sandboxes
judges or evaluators
And when that moment arrives, teams often improvise:
ad-hoc containers
shared runtimes
partial isolation
patched security
It works — until scale or risk appears.
Execution is becoming a platform primitive
Modern architecture already treats some capabilities as foundational:
storage
networking
identity
observability
But dynamic execution is quietly joining that list.
Not as a developer convenience —
as infrastructure.
Because execution surfaces introduce real constraints:
isolation boundaries
resource limits
determinism
tenant separation
failure containment
Those are infrastructure concerns, not app logic.
The gap most teams don’t plan for
Many platforms evolve like this:
Need configurable logic
Add scripting or plugins
Add isolation later
Add limits later
Add observability later
Execution becomes layered retroactively.
That path accumulates risk and complexity.
A dedicated execution runtime flips the model:
execution is isolated by design
limits are enforced at the boundary
failures are contained
integration is explicit
Why this matters now
AI agents, automation, and extensible platforms are increasing the need for:
safe code evaluation
deterministic tool execution
multi-language support
tenant-safe runtime environments
Execution is no longer niche.
It’s becoming a shared substrate across product categories.
A design perspective
Treat execution like a capability layer, not an implementation detail.
That shift changes architecture decisions:
clearer boundaries
safer extensibility
predictable operations
composable integration
And it prevents the most common long-term issue:
execution logic leaking into the core system.

Why We Built a Dedicated Execution Engine Instead of Embedding Code Runners Everywhere

TotyLabs — Thu, 19 Feb 2026 03:00:11 +0000

In many platforms, code execution appears as a secondary feature: scripts inside services, plugins inside apps, or embedded runtimes glued into existing systems.
We took a different path with GozoLite: treating execution as a first-class infrastructure capability.
Instead of distributing execution logic across multiple services, we centralized it into a dedicated execution engine with explicit operational boundaries.
This decision came from observing recurring issues in distributed execution setups:
inconsistent isolation guarantees
duplicated runtime handling
unclear failure modes
fragmented observability
security drift across services
By isolating execution into a focused engine, we gained:
Deterministic execution contracts
Every run follows the same submit() model with explicit limits and outcomes.
Uniform sandboxing
CPU, memory, time, and output limits enforced consistently across 30+ runtimes.
Operational clarity
Execution lives in one deployable unit with predictable scaling and failure behavior.
Security boundaries
Clear separation between host platform and untrusted code execution.
Observability surfaces
Health, diagnostics, capabilities, and structured execution logs exposed natively.
This architecture turns code execution from an embedded feature into a reusable platform capability.
Instead of each service reinventing safe execution, the platform provides it once — correctly and observably.
That shift changes how systems evolve: execution becomes composable infrastructure, not scattered logic.

🧱 Execution Is a System Boundary, Not a Feature

TotyLabs — Tue, 17 Feb 2026 14:32:14 +0000

Running untrusted code is no longer a niche problem.
It appears everywhere:
AI platforms executing user prompts
Online judges running submissions
Automation systems evaluating scripts
Dev tools executing plugins or extensions
And yet, many systems still rely on partial isolation or ad-hoc sandboxes.
That’s increasingly risky.
The Reality of Modern Code Execution
When code execution becomes part of a platform, three things matter:

Isolation must be real Not process-level. Not “best effort.” Actual containment boundaries.
Limits must be enforced CPU, memory, time, output. Otherwise execution becomes denial-of-service waiting to happen.
Failure must be predictable Timeouts, toolchain absence, runtime errors — all explicit. No silent undefined behavior. Secure execution isn’t about running code. It’s about controlling execution as a system capability. Execution Is Infrastructure Treating execution as infrastructure changes design: Stateless execution units Deterministic lifecycle Container-level isolation Explicit contracts Observability of runs At that point, execution stops being a risk surface and becomes a platform primitive. Why This Matters Now AI systems accelerated this shift. Agents write and run code. Users submit code dynamically. Plugins execute externally sourced logic. Execution moved from backend detail to product surface. Security expectations moved with it. A Practical Direction One effective pattern emerging: containerized runtimes per-execution lifecycle strict resource enforcement centralized runtime registry explicit execution API This model scales from: dev tools to education to AI platforms to infra systems without changing the core execution contract. Closing Thought Execution isn’t a feature. It’s a boundary. And systems that define their boundaries clearly are the ones that scale safely.

Secure Code Execution Is Not Just Sandboxing — It’s System Design

TotyLabs — Tue, 17 Feb 2026 03:26:00 +0000

When people hear secure code execution, they often think about one thing:
“Run code in a container.”
That’s a start.
But in real infrastructure, secure execution is not a container feature.
It’s a system.
And most platforms underestimate what that actually means.
The Misconception: Containers = Security
Containers provide isolation primitives:
namespaces
filesystem boundaries
process separation
But secure execution requires much more than that.
Because the moment you execute untrusted code, you inherit risks across multiple dimensions:
resource exhaustion
fork bombs
infinite loops
memory abuse
toolchain escapes
noisy neighbor effects
scheduler starvation
A container alone doesn’t solve those.
What Secure Code Execution Actually Requires
In production environments, safe execution needs layered controls:

Explicit resource enforcement CPU quotas memory limits timeouts output caps Execution must be bounded, not trusted.
Deterministic failure modes A secure executor must never hang or degrade silently. Every run should end in: success compile error runtime error timeout limit exceeded Nothing undefined.
Execution lifecycle isolation Each execution should have: ephemeral environment fresh filesystem isolated process tree controlled teardown No cross-run residue.
Runtime surface control Languages aren’t equal. Compiled runtimes, interpreters, and toolchains behave differently under isolation. A secure executor must normalize: invocation limits IO exit semantics Across all runtimes. Secure Execution Is Infrastructure Once you layer: limits isolation lifecycle observability runtime control You’re no longer building a feature. You’re building infrastructure. This is why platforms that execute user code internally often evolve toward dedicated execution systems instead of ad-hoc containers. Why This Matters Now Modern platforms increasingly run external or user-provided code: online judges AI tools automation engines workflow platforms education environments Secure execution is becoming a core capability, not a niche tool. Closing Thought Containers provide isolation. Secure execution requires architecture. If your platform executes code, the boundary of safety is not Docker. It’s the system you design around it.

Building a Production-Grade Self-Hosted Code Execution Engine (Isolation, Limits, Observability)

TotyLabs — Sun, 15 Feb 2026 18:56:53 +0000

Running untrusted code safely in production is one of those problems that looks simple — until you actually have to operate it.
Over the past year I’ve been building a self-hosted polyglot execution backend designed for real workloads rather than demos or sandboxes.
Some principles that proved essential:

Isolation must be structural, not optional Each execution runs inside its own container with strict CPU, memory, time, and output limits. No shared runtime, no trust assumptions.
Deterministic failure modes matter Missing toolchains, timeouts, or resource violations are explicit states — not crashes. Execution systems must fail predictably to be operable.
Stateless execution enables scaling Containers are ephemeral and disposable. The platform scales horizontally without session coupling.
Observability is part of the contract Health, diagnostics, capabilities, and structured execution logs are exposed as first-class endpoints. You can’t operate what you can’t see.
Safety limits define reliability Resource enforcement (ulimits, cgroups, container quotas) is not just security — it’s stability. Most outages in execution systems come from missing limits. This kind of architecture is useful for: online judges AI tool execution automation platforms education sandboxes CI runners If you’re working on similar infra or self-hosted execution systems, I’d love to exchange notes. GitHub: https://github.com/TotyLabs Demo: https://huggingface.co/TotyLabs/GozoLite

Secure Polyglot Code Execution: How to Run Untrusted Code Safely

TotyLabs — Sat, 14 Feb 2026 10:15:49 +0000

Running user code in production systems is dangerous by default.
Whether you're building:
an online judge
an AI agent runtime
a code playground
a workflow automation engine
or a CI runner
you eventually face the same question:
How do you execute untrusted code safely?
This post explains the architecture behind a secure polyglot code execution system designed for running multiple programming languages inside isolated sandboxes.
What Is Secure Code Execution?
Secure code execution means:
Running arbitrary user-provided code without allowing it to escape, abuse resources, or affect the host system.
This requires combining multiple isolation and control layers:
container sandboxing
syscall filtering
resource limits
network restrictions
execution quotas
validation
No single mechanism is enough.
Security comes from composition.
Polyglot Code Execution Architecture
A production-grade multi-language code executor typically follows this pipeline:
Copiar código

Request
→ authentication
→ rate limiting
→ quota check
→ code validation
→ sandboxed execution
→ result capture
→ telemetry
Each stage reduces risk.
Each stage is observable.
Sandboxed Execution with Containers
The core isolation layer is usually container-based.
A sandboxed execution container enforces:
CPU limits
memory limits
execution timeouts
filesystem isolation
process limits
no privileged access
This ensures the executed program cannot affect the host or other tenants.
Syscall Filtering (seccomp)
Even inside containers, processes can still call dangerous syscalls.
So secure code runners apply seccomp filters to restrict:
networking syscalls
kernel module access
device access
mount operations
namespace escapes
The executed program only sees a minimal syscall surface.
Running Multiple Languages Safely
Polyglot execution adds extra challenges:
different compilers/interpreters
toolchain detection
runtime dependencies
language-specific exploits
A robust multi-language code executor uses:
per-language toolchain images
deterministic execution contracts
explicit capability detection
standardized resource policies
So Python, C++, Rust, Go, and others run under the same security model.
Preventing Abuse and Resource Exhaustion
Execution platforms must defend against:
infinite loops
fork bombs
memory exhaustion
output flooding
rapid request bursts
Typical controls include:
CPU time limits
memory caps
stdout size limits
process count limits
per-tenant quotas
rate limiting
Execution becomes bounded.
Network Isolation for Untrusted Code
Untrusted code should not freely access the internet.
Secure execution sandboxes usually enforce:
no outbound network by default
DNS filtering
allowlisted destinations
egress firewall rules
This prevents data exfiltration and external abuse.
Observability in Code Execution Systems
You cannot secure what you cannot observe.
A secure code execution platform should emit:
execution duration
timeout rates
memory usage
container failures
quota saturation
anomaly signals
Security becomes measurable, not assumed.
Typical Use Cases for Secure Code Execution
Secure polyglot execution systems power:
online judges
AI coding agents
notebook backends
education platforms
plugin runtimes
workflow automation
CI job isolation
Anywhere user code runs, sandboxing is required.
Key Takeaways
Running untrusted code safely requires:
container sandboxing
syscall filtering
strict resource limits
network isolation
validation layers
observability
Secure execution is not a feature.
It’s an architecture.

GozoLite — A Production-Grade Polyglot Code Execution Engine (Open Source)

TotyLabs — Fri, 13 Feb 2026 19:14:19 +0000

Modern platforms increasingly need to execute untrusted code safely — from AI agents and online judges to automation pipelines and developer tooling.
Most solutions either sacrifice isolation, performance, or language coverage.
GozoLite is an open-source polyglot code execution engine designed to run 30+ programming languages inside secure, resource-constrained sandboxes — with production-grade observability and explicit execution contracts.
Why GozoLite exists
Executing arbitrary code in multi-tenant environments is fundamentally a systems problem:
Isolation boundaries must be explicit
Resource limits must be deterministic
Toolchains must be validated
Failures must be observable
Execution must degrade safely
GozoLite was built around these constraints from the ground up.
Core architecture
At its core, GozoLite is a stateless execution service with:
Container-level isolation (Docker)
Strict ulimit enforcement (CPU, memory, file size, processes)
Language registry with toolchain detection
Standardized execution contract
Structured logs and diagnostics
Deterministic timeouts and output limits
Each execution is treated as a bounded, auditable event — not a best-effort script run.
Polyglot by design
GozoLite supports over 30 programming languages via a central registry and consistent interface.
Examples:
Python
C / C++
Rust
Go
Java
Node.js
Bash
And more
All languages share the same execution pipeline and limits model.
Execution model
A typical request:
Json
Copiar código
POST /execute
{
"language": "python",
"code": "print(21*2)"
}
Response:
Json
Copiar código
{
"status": "ok",
"stdout": "42\n",
"time_ms": 18,
"memory_kb": 5120
}
Failures are explicit:
Json
Copiar código
{
"status": "failed",
"error": "TOOLCHAIN_MISSING"
}
This makes GozoLite predictable inside larger systems.
Security model
GozoLite applies layered sandboxing:
Container isolation
Read-only filesystem segments
Resource ceilings (CPU/mem/proc)
No network by default
Output size caps
Execution time caps
The goal is not “best effort safety”, but controlled execution boundaries.
Observability first
Unlike typical code runners, GozoLite exposes:
Capabilities (available languages/toolchains)
Health status
Diagnostics
Execution metrics
This makes it suitable for production pipelines, not just demos.
Use cases
GozoLite is used or designed for:
Online judges
AI agent sandboxes
Code playgrounds
Education platforms
Secure automation
Multi-tenant developer tools
Open source
GozoLite is fully open-source and intended for:
Educational environments
Self-hosted execution services
Research and experimentation
Enterprise evaluation
Repository:
https://github.com/TotyLabs/GozoLite�
Final notes
Secure code execution is often treated as an implementation detail.
In reality, it is infrastructure.
GozoLite approaches execution the way databases approach queries:
bounded, observable, and contract-driven.
If you're building systems that run user or AI-generated code,
you need execution you can reason about.
That’s the problem GozoLite solves.

What Secure Code Execution Actually Requires

TotyLabs — Thu, 12 Feb 2026 14:13:03 +0000

Everyone claims to offer secure code execution.
But most platforms that run code — whether online judges, sandbox APIs, or embedded execution engines — rely on surface-level protections and call it a day.
Timeouts.
Basic containerization.
Maybe a memory limit.
That’s not security. That’s hope.
If you’re running arbitrary code — especially in production — “secure” has to mean something far stricter.
Let’s break down what secure code execution actually requires.
1️⃣ Hard Resource Boundaries (Not Just Timeouts)
A timeout prevents infinite loops.
It does not prevent:
Memory exhaustion attacks
Fork bombs
CPU starvation
File descriptor abuse
True secure execution requires:
Hard CPU caps (cgroups)
Hard memory limits
Process limits
I/O constraints
Strict execution time enforcement
Without these, one malicious script can degrade or crash the host.
2️⃣ Real Isolation (Ephemeral & Disposable)
Many systems reuse containers.
That’s a risk.
A secure execution engine should:
Spawn fresh, ephemeral containers per execution
Share no state between runs
Destroy the environment immediately after completion
Avoid persistent writable layers
Execution must be disposable.
If state persists, attack surfaces accumulate.
3️⃣ Network Boundaries
Unrestricted network access turns a sandbox into a pivot point.
Secure systems must define:
Explicit outbound policies
No internal network visibility
No host access
No privilege escalation
Isolation is not just filesystem-level.
It’s network-level.
4️⃣ Predictable Failure Modes
Security is not just about prevention — it’s about behavior under stress.
A secure execution engine must:
Fail fast under overload
Enforce quotas per tenant
Maintain isolation during concurrent execution
Provide deterministic limits
If your execution engine collapses under concurrency, it’s not secure — it’s fragile.
5️⃣ Clear Architectural Boundaries
Secure code execution is an architectural discipline, not a feature toggle.
A production-ready model requires:
A thin API layer
A strict orchestration component
A container manager
Centralized signed logging
Auditable execution traces
Clean separation between control plane and execution plane
Security is systemic. Not decorative.
Why This Matters
We’re entering an era where:
AI agents execute real code
Educational platforms run untrusted snippets
Internal tooling automates infrastructure tasks
DevOps workflows trigger dynamic execution
The attack surface is expanding.
If “secure” only means “Docker + timeout,” we are underestimating the problem.
What Secure Code Execution Should Mean
A secure execution engine should guarantee:
✓ Hard CPU limits
✓ Hard memory caps
✓ Process isolation
✓ Ephemeral environments
✓ Network confinement
✓ Deterministic failure modes
✓ Auditable logs
Anything less is convenience — not security.
Final Thought
The real question isn’t:
“Does it run code?”
It’s:
“What happens when that code tries to break your system?”
If you’re building or adopting a code execution engine, ask the hard questions.
Security is not a checkbox.
It’s an architectural stance.

Most Code Execution Engines Are Not Actually Secure

TotyLabs — Wed, 11 Feb 2026 20:59:51 +0000

When people search for a “code executor,”
they usually care about one thing:
Does it run?
Almost nobody asks the more important question:
Is it secure?
And that’s a problem.
The Illusion of Sandboxing
Many platforms claim to provide “sandboxed execution.”
But what does that actually mean?
Are CPU limits enforced at the OS level?
Is memory capped with real isolation?
Are syscalls restricted?
Is output bounded?
Are timeouts deterministic?
Is multi-tenant isolation truly separated?
Or is it just a Docker container with default settings?
Security is not marketing. It’s architecture.
What Secure Code Execution Actually Requires
A secure code executor must guarantee:
✔ Hard CPU limits
✔ Hard memory caps
✔ Execution timeouts
✔ Output limits
✔ Controlled filesystem access
✔ Restricted network access
✔ Deterministic failure modes
✔ Clear audit logs
And most importantly:
✔ Predictable isolation boundaries
Without these, you're not running secure execution. You're running hopeful execution.
Why This Matters Now
AI systems. Online judges. Education platforms. Internal automation layers.
They all execute untrusted code.
If your execution engine leaks, hangs, over-consumes resources, or breaks tenant boundaries —
You don’t have a feature problem.
You have an infrastructure risk.
Security Is the Core Layer
Secure code execution is not about:
“Can it run 30 languages?”
It’s about:
“What happens when someone tries to break it?”
That’s where architecture matters.
If you're building a platform that executes code, security is not optional.
It is the product.

🚨 The Hidden Problem Most Developers Face When Building Projects

TotyLabs — Wed, 11 Feb 2026 01:21:18 +0000

Most developers don’t fail because they can’t code.
They fail because they build without structure.
You’ve probably felt this:
You start a project excited.
You ship fast.
You add features.
You “refactor later.”
Six months later… the system is fragile.
You’re afraid to touch it.
You start a new project instead.
It’s not a skill issue.
It’s a systems mindset issue.
The Real Problem
Most devs think like builders.
Very few think like architects.
They focus on:
Features
Speed
Stack
Framework trends
But they ignore:
Contracts
Failure modes
Execution boundaries
Isolation
Operational predictability
And when the project grows, chaos appears.
The Career Version of This
It’s the same in work life.
You:
Say yes to everything.
Take on more tasks.
Ship fast.
Don’t define boundaries.
Don’t stabilize your base.
Eventually you burn out.
Or your project collapses under its own weight.
What Changed for Me
When I started building infrastructure instead of apps, something shifted.
Instead of asking:
“How fast can I ship this?”
I started asking:
“How does this fail?”
“What are the execution limits?”
“What happens under abuse?”
“What is the contract?”
That’s how GozoLite was built.
Not as a “code runner”.
But as a system with:
Explicit execution contracts
Defined resource limits
Isolation boundaries
Controlled architectural freeze
Because in B2B systems, stability beats speed.
Final Thought
If you want your projects to survive:
Stop optimizing for launch. Start optimizing for structure.
Most devs don’t lack talent.
They lack architecture discipline.

🛡️ The Future of Code Execution Is Self-Hosted

TotyLabs — Mon, 09 Feb 2026 16:13:56 +0000

Over the last few years, remote code execution APIs have exploded.
They’re convenient.
They’re fast.
They abstract everything away.
But there’s a silent trade-off almost nobody talks about:
Your code isn’t just code. It’s intellectual property.
In the AI era, sending internal logic, proprietary algorithms, or user submissions to third-party execution engines isn’t just a technical choice.
It’s a strategic decision about control.
So the real question becomes:
Do you want your platform’s execution layer to depend on infrastructure you don’t control?
The Current Execution Model
Most execution platforms today:
Depend on external APIs
Charge per execution
Introduce vendor lock-in
Process sensitive logic outside your infrastructure
Abstract away operational visibility
For experimentation?
That’s fine.
For production systems handling real users and proprietary logic?
That’s a different conversation.
The Strategic Alternative: Execution Sovereignty
When I built GozoLite, the architectural principle was clear:
If you execute code, you should control the environment.
Not just the API surface.
The runtime.
The isolation model.
The resource limits.
The failure modes.
That means:
✔ Modular architecture
✔ Multi-language support (29 runtimes)
✔ Explicit isolation boundaries
✔ Deterministic resource limits
✔ Fully self-hosted capability
✔ No mandatory external dependency
Execution should be portable.
Deployable.
Inspectable.
Governable.
Where Sovereign Execution Actually Matters
Education Platforms
Run student code without per-request pricing pressure.
Own your infrastructure cost model.
Technical Interview Systems
Deploy a sandbox tailored to your hiring workflows, not a generic API abstraction.
Enterprises
Avoid sending proprietary business logic through third-party execution layers.
AI & ML Teams
Keep full control over data flow, execution pipelines, and model-adjacent computation.
When execution is core to your product, outsourcing it blindly becomes a liability.
The Hidden Engineering Reality
Supporting 29 languages in a unified modular architecture isn’t “just Docker.”
You’re dealing with:
Compiled vs interpreted runtime models
Consistent execution contracts
Memory ceilings and CPU quotas
Timeout enforcement
Output limits
Tenant isolation
Deterministic failure modes
At that point, architecture isn’t implementation detail.
It’s the product.
The Bigger Shift
The future isn’t simply serverless.
It’s:
Portable
Modular
Observable
Self-governed
Sovereign
If your platform executes user code, the infrastructure decision defines:
Your security posture
Your cost structure
Your operational risk
Your vendor exposure
Your long-term flexibility
Execution is not a utility.
It’s a strategic layer.
And the teams that control it will control far more than they realize.