Runtime Configuration
Resource limits, monitoring, and production deployment settings
Configuration File
NANO uses JSON configuration to define apps, resource limits, and runtime behavior.
{
"server": {
"port": 8080,
"host": "0.0.0.0"
},
"apps": [
{
"hostname": "api.example.com",
"entrypoint": "./app.js",
"limits": {
"workers": 4,
"memory_mb": 128,
"timeout_secs": 30,
"cpu_ms": 50
}
}
]
}
CPU Time Limits
Per-request CPU limits prevent infinite loops and resource exhaustion. Timer-based termination ensures clean shutdown without V8 corruption.
Configuration
{
"limits": {
"cpu_ms": 50
}
}
Timer-Based Termination
Uses timer_create() on Linux and getrusage() on macOS to track per-thread CPU time. Termination signals originate from the main thread to avoid V8 signal handler limitations.
- Default: 50ms per request (matches Cloudflare Workers)
- Configurable per-app
- Clean termination without isolate corruption
Memory Management
Per-isolate memory limits with 4-tier pressure monitoring and LRU eviction prevent OOM conditions.
Configuration
{
"limits": {
"memory_mb": 128
}
}
Memory Pressure Levels
- Normal - Below 70% usage
- Warning - 70-85% usage
- Critical - 85-95% usage
- Emergency - Above 95% usage
Eviction Strategies
- Soft Eviction - Allows current requests to complete
- LRU Eviction - Prefer stateless isolates
- Emergency - Immediate termination
Per-Tenant Metrics
Automatic metrics collection per hostname with Prometheus exposition format at the /_admin/metrics endpoint.
# HELP nano_requests_total Total HTTP requests
# TYPE nano_requests_total counter
nano_requests_total{hostname="api.example.com",status="200"} 1423
# HELP nano_request_duration_ms Request latency
# TYPE nano_request_duration_ms histogram
nano_request_duration_ms_bucket{hostname="api.example.com",le="10"} 892
# HELP nano_cpu_time_ms CPU time per request
# TYPE nano_cpu_time_ms histogram
nano_cpu_time_ms_bucket{hostname="api.example.com",le="50"} 1387
# HELP nano_memory_bytes Memory usage per isolate
# TYPE nano_memory_bytes gauge
nano_memory_bytes{hostname="api.example.com",isolate="iso-1"} 16777216
Collected Metrics
- Request counts by hostname and status code
- Latency histograms (p50, p95, p99)
- CPU time per request
- Memory usage per isolate
- Context reset counts
- Active isolates count
WebAssembly Support
V8 built-in WASM engine for executing binary modules in isolates. No external dependencies required.
const wasmModule = await WebAssembly.compile(wasmBytes);
const instance = await WebAssembly.instantiate(wasmModule, {
env: { memory: new WebAssembly.Memory({ initial: 1 }) }
});
const result = instance.exports.add(1, 2);
Features
- Module compilation and instantiation
- Memory and table imports/exports
- Source hash caching for integrity
- Magic number and version validation
- Sliver integration for portable WASM apps
Worker Pool
Per-app worker pools handle requests with configurable size and bounded queues.
Configuration
{
"limits": {
"workers": 4
}
}
Each worker maintains a thread-local isolate with 256-slot bounded channels for backpressure. Context reset between requests provides isolation with ~5ms overhead.
Performance Tuning
Sliver Caching
{
"slivers": {
"enabled": true,
"cache_size": 100
}
}
Enable sliver caching for faster cold starts on frequently accessed apps.
Timeout Configuration
{
"limits": {
"timeout_secs": 30
}
}
Request timeout in seconds. Requests exceeding this limit are terminated.
Admin API
Optional administrative endpoints for monitoring and management.
| Endpoint | Description |
|---|---|
| GET /_admin/metrics | Prometheus metrics |
| GET /_admin/health | Health check |
| GET /_admin/isolates | Isolate status |