Skip to main content
To run Figranium reliably, it is essential to provision your hosting environment with sufficient resources. Figranium runs in a containerized environment powered by Playwright and Chromium. While the backend Node.js application is highly efficient, browser automation and page rendering are resource-heavy tasks. This guide outlines the recommended hardware specifications for self-hosting Figranium.

​
Resource Tier Quick Reference

​
Hosting Tiers

Sub-Minimum (Low-Spec Hosting)

Figranium is highly portable and can boot and run with 1 GB of RAM on low-end VPS instances or similar constrained environments.However, 1 GB of RAM is not recommended for normal or production workloads:
  • Memory Starvation: With only 1 GB of RAM, Chromium and Figranium have little headroom under heavier pages or workloads, increasing the risk of out-of-memory errors (ENOMEM), abrupt task terminations, and browser context crashes.
  • CPU Bottlenecks: Single-core low-power processors will experience significant slowdowns during page load execution, script evaluation, and proxy negotiation.
  • No Video/Screenshot Buffers: Automating multiple concurrent browsers or capturing video logs under these conditions will likely result in heavy latency or failed executions.

Minimum Smooth (Baseline Reliability)

This is the recommended baseline for running single-threaded, scheduled workflows, lightweight data extraction, and periodic scraping tasks without performance issues.
  • CPU: 1 vCPU
  • RAM: 2 GB of RAM — optimized for typical Figranium workloads
  • Shared Memory: At least 512 MB of shared memory (/dev/shm) allocated to the Docker container.
  • Workload Scope: Suitable for executing a single task at a time, performing API extraction, or basic web scraping without extensive media capture.

Sweet Spot (Recommended in Production)

This specification is highly recommended for production environments. It ensures snappy UI response times, smooth concurrent scheduling, and optimal browser execution.
  • CPU: 2 vCPUs (or more)
  • RAM: 4 GB of RAM — the sweet spot for Figranium
  • Shared Memory: 1 GB of shared memory (/dev/shm) allocated to the Docker container.
  • Workload Scope: Highly stable. Handles multiple concurrent tasks, heavy workflows, extensive screenshots, high-resolution video recordings, and environments such as Headful Execution for troubleshooting or Headful Debugging.

​
Why Shared Memory (/dev/shm) Matters

Chromium utilizes /dev/shm (shared memory) for rendering pages and passing frames.
By default, Docker allocates only 64 MB to /dev/shm, which is insufficient for modern web pages and will lead to browser tab crashes (e.g., Target closed or Session crashed errors).
For standard Docker Compose environments, ensure shm_size is configured appropriately:
For more details on resolving container resource exhaustion, see our Troubleshooting guide.

​
Docker Resource Limits

If you are deploying Figranium on shared infrastructure or Kubernetes, we recommend setting CPU and Memory limits to protect your host while ensuring the containers do not get throttled:

​
Storage Considerations

Because Figranium captures screenshots, records videos of executions, and can store extensive database transaction history, storage speed and capacity should be matched to your usage:
  • Use Solid State Drives (SSD): Figranium utilizes file-based persistent storage (by default) and heavily interacts with the disk during logging and browser state preservation. SSDs prevent disk-write bottlenecks.
  • Video Recording & Captures: Automated recordings consume more CPU and disk space. If you automate a large volume of tasks, disable automated recording inside the General Settings panel of your tasks and clear old captures periodically with Clear captures in Settings > Advanced, or set a shorter retention period. See Performance & Optimization for instructions on maintaining a clean storage footprint.