The problem
ONNX image segmentation and native image libraries retained memory between jobs, making a normal long-running worker unsafe on a small production server.
Back to selected work
03Project mission dossier
Image processing infrastructure · 2026
Picnexa
A stateless image-processing platform for compression, format conversion, and AI background removal, engineered for a constrained ARM server.
- Role
- Full-stack developer & deployment owner
- Status
- Deployed to production
Project snapshot
- Role
- Full-stack developer & deployment owner
- Status
- Deployed to production
- Platform
- Web frontend and ARM API
- Deployment
- Vercel + Oracle Cloud Docker
- Scope
- Compression, conversion and AI background removal
- Repository
- No public repository
The solution
Every background-removal job runs in a disposable child process. The operating system reclaims native memory after completion, while queues, limits, validation, and temporary storage keep workloads bounded.
Technical system
Verified components and boundaries found in the project source and documentation.
- 01Next.js frontend
Vercel interface and direct uploads
- 02Caddy boundary
HTTPS and exact-origin CORS
- 03Fastify API
Validation, rate limits and bounded queue
- 04Disposable AI worker
One ONNX process per background job
- 05Temporary storage
Request-scoped files removed after use
12.53 MPAI image tested
~1.86 GiBworker peak
0 Bswap used
What it does
Disposable isolated AI workers
Defensive file and pixel validation
Bounded queue and temporary storage
Docker, Caddy, HTTPS, metrics, and structured logs
Product walkthrough02
Engineering decisions
Native memory is not the JS heap
ONNX and Sharp retained native allocations between jobs beyond JavaScript heap control.
- Decision
- Run every background-removal job in a disposable child process and terminate it on completion or timeout.
- Engineering effect
- The operating system reclaims native memory and the API returns to its idle baseline.
Quality inside hard limits
Higher-quality segmentation competes directly with a single OCPU and bounded container memory.
- Decision
- Tune model, dimensions, concurrency, queue capacity, Sharp caches, and container limits as one system.
- Engineering effect
- A verified 12.53 MP input completed below the 3 GiB container limit without swap.
Ownership map
Full-stack developer & deployment owner
- 01
Designed the frontend/API deployment split
- 02
Built image processing, validation, queues, and worker isolation
- 03
Containerized and deployed the ARM production stack
Outcome
The production benchmark processed a 3072 × 4080 image with the higher-quality model below a 3 GiB container limit and returned memory to baseline without swap usage.
Arij Maison
Premium commerce storefront