Capability profiles & security
minimal, docker, full -- isolation levels, read-only rootfs, Docker-in-Docker, and when to use each.

Every plan has a capability profile (capSet)
The capSet determines your instance's isolation level, what capabilities it has, and whether it can run Docker-in-Docker.
| Profile | Rootfs | AppArmor | no-new-privileges | Docker-in-Docker | Best for |
|---|---|---|---|---|---|
minimal | Read-only | Custom profile | Yes | No | Untrusted workloads, CI runners, shared hosting |
docker | Writable | unconfined (seccomp) | No | Yes | Apps, Docker Compose, DinD, build pipelines |
full | Writable | unconfined | No | Yes | KVM, GPU, kernel modules, dedicated plans only |
What each profile means
minimal — Maximum isolation
- Root filesystem read-only -- persistent data must go in volumes or
/var/lib/docker - Custom AppArmor profile blocks
/sys/** w,/proc/** w,/boot/** w, mount/umount/ptrace/syslog no-new-privileges-- prevents privilege escalation- Baseline caps only (CHOWN, DAC_OVERRIDE, FOWNER, KILL, SETGID, SETUID, NET_BIND_SERVICE, NET_RAW, SYS_CHROOT, MKNOD, AUDIT_WRITE)
- No
CAP_SYS_ADMIN,CAP_NET_ADMIN,CAP_SYS_PTRACE,CAP_SETFCAP - No Docker daemon access
Best for: Untrusted customer code, CI/CD runners, shared multi-tenant workloads.
docker — Docker-in-Docker (default for app plans)
- Full Docker daemon inside the instance (DinD)
CAP_SYS_ADMINfor nested mount/cloneCAP_NET_ADMINfor bridge/network managementsystempaths=unconfinedfor session keyring accesscgroupns=hostfor cgroup v2 controller delegation- Custom seccomp profile allows
keyctl,pivot_rootfor nested runc
Best for: Application hosting, Docker Compose, CI/CD with Docker.
full — Privileged (dedicated plans only)
--privileged-- all capabilities- Access to
/dev/kvm,/dev/dri,/dev/vfio(if present on host) - Kernel module loading
Best for: KVM/libvirt, GPU workloads, kernel development, single-tenant dedicated hardware.
Network security (all profiles)
| Control | Implementation |
|---|---|
| Per-instance firewall | iptables chain NAIRACLOUD->instanceId< in FORWARD |
| Egress deny | SMTP (25), metadata, control plane IP blocked |
| Inter-instance isolation | FORWARD DROP docker0→docker0 |
| Website edge | One Caddy on the node owns 80/443; Host header selects the instance, unknown Hosts return 404 |
If the runtime monitor ever detects a breakout attempt, the node auto-suspends the instance. You get a 2-day window to appeal. See Instance quarantines & appeals.
Disk isolation (all plans)
Each instance gets a dedicated ext4 disk image (sized to plan's storageGb), loop-mounted at /var/lib/docker inside the container. The instance sees only its allocated GB -- not the host's total disk.
Instance identity
- Instance ID: non-enumerable
cuid - Public IP: the node's IPv4, shared by instances on that node
- Private IP: 10.20.0.x on the node's data network
- SSH port: persisted across rebuild
- Website host:
<hostname>.nairacloud.xyzfor the defaultwebsite;<label>-<hostname>.nairacloud.xyzfor other sites, routed by the node edge
Practical -- try it now
Check your instance's profile
- SSH into your instance
- Run:
cat /run/nairacloud/credentials.conf