These partitioning recommendations draw from the Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) library. Poolside does not provide STIG-specific implementation guidance or support for customer-defined STIG policies.
Partitioning overview
This page shows recommended partition sizing for single-node Poolside on-premises deployments running RKE2 and explains how model checkpoints affect storage requirements. The checkpoint estimates cover these model artifacts:
| Model | Checkpoint size (GB) |
|---|
| laguna_m_fp8_fp8kv_re_04_2026 | 214 |
| laguna_xs_fp8_fp8kv_re_04_2026 | 33 |
| point_v2_04_2026 | 25 |
STIG-compliant partition recommendations
For STIG-hardened Linux nodes, Poolside recommends the following partition layout and sizing as a minimum for the listed models:
| Mount | Size | Filesystem | Mount options | Purpose |
|---|
/boot/efi | 600M | fat32 | umask=0077 | UEFI system partition |
/boot | 1G | xfs | nodev,nosuid | Kernel, initramfs |
/ | 50G | xfs | defaults | OS root |
/tmp | 2G | xfs | nodev,nosuid,noexec | Temporary files |
/var | 5G | xfs | nodev,nosuid | Cache, spool, backups |
/var/tmp | 10G | xfs | nodev,nosuid,noexec | Temporary files |
/var/log | 50G | xfs | nodev,nosuid,noexec | System + audit logs |
/var/lib | 400G | xfs | nodev,nosuid | kubelet, rancher, containers |
/home | 50G | xfs | nodev,nosuid | Terraform working directories |
/opt/poolside | 350G | xfs | nodev,nosuid | SeaweedFS, registry, PostgreSQL |
| swap | 4G | swap | none | Swap space |
Dedicated /opt/poolside partition for STIG compliance
STIG controls recommend dedicated partitions to prevent system partitions from filling up and causing denial of service. Poolside recommends placing all Poolside application data (SeaweedFS, container registry, PostgreSQL) on a dedicated /opt/poolside partition rather than the root filesystem. Without separation, application data growth can render the OS unusable.
Inference storage impact
When you run inference workloads, the workloads load model checkpoints from SeaweedFS into storage-backed emptyDir volumes under /var/lib/kubelet. This means you store two copies of the model checkpoint on disk: one copy in SeaweedFS and one copy in the emptyDir volume.
Each inference workload consumes disk space equal to its model checkpoint size:
| Model | Checkpoint size (GB) | emptyDir consumption (GB) | Total disk usage (GB) |
|---|
| laguna_m_fp8_fp8kv_re_04_2026 | 214 | 214 | 428 |
| laguna_xs_fp8_fp8kv_re_04_2026 | 33 | 33 | 66 |
| point_v2_04_2026 | 25 | 25 | 50 |
/var/lib to accommodate your largest model’s checkpoint size when running inference.
Trajectory growth calculations
Based on usage data, use the following calculations to estimate how much trajectory storage to allocate for your Poolside deployment:
Trajectories record every agent interaction and grow continuously. Plan your
storage before deployment to avoid capacity issues.
- User trajectories per month:
[ users × sessions/user/day × active days/mo × 1.25 MB ]
- Job trajectories per month:
[ jobs × runs/job/day × days/mo × (events/run × 5 KB) ]
The sum of these two calculations provides the recommended trajectory storage for your Poolside deployment and accounts for growth over time.
Example calculation:
- 100 users, 50 sessions/day, 20 active days/month, 1.25 MB/session
- 50 jobs, 100 runs/job/day, 100 events/run, 31 days/month, 5 KB/event
Total trajectory storage needed:
- User trajectories per month:
100 * 50 * 20 * 1.25 MB = 125,000 MB = 125 GB
- Job trajectories per month:
50 * 100 * 31 * (100 * 5 KB) = 77,500,000 KB = ~77.5 GB
Total trajectory storage growth per month: 125 GB + 77.5 GB = 202.5 GB
Scaling prioritization guidance
If you need to scale storage, allocate additional space in this priority order:
/var/lib: Scales per model deployed in-cluster/opt/poolside: Scales with model checkpoints and trajectory data/home: Scales with Terraform files. The Poolside Terraform bundle packages container upgrade images.
Core OS partitions (/, /boot, /tmp, /var, /var/tmp, /var/log) can remain fixed regardless of total disk size.
STIG mount option recommendations
/tmp, /var/tmp, and /var/log should have noexec set in the mount options to prevent code from running in temp directories./var/lib cannot have noexec. The container runtime runs binaries from overlay layers stored there. Adding noexec here breaks Kubernetes pods.
