Container Runtime Configuration
The runtime configuration specifies how a container starts, information it has access to, and permissions it has on the host. It needs to be enabled for the settings underneath to have an effect.
Environment Variables
This section shows the currently configured environment variables for the container and also allows for a user to add/remove additional environment variables to the container after it's been created.
To add additional environment variables to a container:
- Add a environment variable to the environment variable fields.
- Use the Add Variable button.
- Repeat the last two steps until all the environment variables for this container have been added.
- Press the Save Config button on the bottom right of the screen.
There are Cycle specific environment variables injected into each container. Find the full list here. Some of these will be instance specific, such as CYCLE_INSTANCE_IPV6_SUBNET.
Environment Variable Management
Environment variables defined on the image cannot be removed. Cycle interprets these as critical. However, their values can be changed, which may be useful for things such as specific development-only settings.
Command
The command section of the runtime configuration settings has options for overriding the startup command used to start the container and the containers configured working directory.
Startup Command
Path - Set an override to the default command run when the container starts.
Args - Any args for the override command.
Use " " 's to wrap arg entries. For example a path that is /bin/sh could have args set to:
-c "sleep '10' && ./script.sh"Working Directory
Workdir - define the full path to be used when setting the containers working directory.
Devices
Use Devices to pass host devices into a container (e.g., USB serial adapters, cameras, hardware security modules) and to control what device operations the container is allowed to perform. This enables sophisticated workloads (encryption, USB mounts, video capture, etc.) while keeping least-privilege controls.
Shared Host Memory
| Field | Description |
|---|---|
| Override | When enabled, lets you set a custom size for the container's shared memory segment (/dev/shm). |
| Shared Host Memory Size | Size of /dev/shm inside the container. Accepts sizes like 64M, 1G, etc. Increase for apps that use shared memory heavily (e.g., browsers, ML, video). |
Max Shared Memory
The maximum size of this shared memory is 6.5GB.
Expose Devices (Device Mapping)
Maps a host device node into the container filesystem by creating the destination device node in the container and binding the host device to it with the specified access.
| Field | Description | Valid values / examples |
|---|---|---|
| Source | Absolute path to the host device node to expose. | e.g., /dev/ttyUSB0, /dev/video0, /dev/mapper/cryptdev |
| Destination | Path where the device appears inside the container. | e.g., /dev/ttyUSB0, /dev/camera0 |
| Options | Access flags for the device inside the container. | Any combination of r (read), w (write), m (mknod). Common: rwm (full access), rw, r. If omitted, defaults to platform/Docker default (typically rwm). |
Device Permissions
Device Permissions control what operations the container is allowed to perform on specific types of devices. These settings correspond to Linux cgroup device rules, which define access based on the device’s type, major, and minor numbers.
| Field | Description | Example / Notes |
|---|---|---|
| Type | The device class — defines whether the device is Block (disk-like, e.g., /dev/sda) or Char (character-based, e.g., serial ports, cameras). | Block = disk, Char = USB, TTY, video |
| Major | The major device number, assigned by the Linux kernel to a driver or device category. Determines which device driver controls the device. | Example: 81 (video devices), 188 (USB serial) |
| Minor | The minor device number, which identifies a specific device instance controlled by that driver. | Example: 0 = /dev/video0, 1 = /dev/video1 |
| Allow | Toggles whether this rule permits (Allow checked) or denies (Allow unchecked) access. Typically, containers have deny-by-default behavior. | Enable this to grant access; disable to explicitly block. |
| Access | The access rights granted to matching devices: r = read, w = write, m = create device nodes (mknod). Combine as needed (rwm, rw, r). | Most common: rw for USB devices; r for cameras; avoid m unless required. |
Order Not Important
Device Permissions do not map one-to-one with devices listed under Expose Devices. Instead, permissions apply to any device whose type and major/minor numbers match the rule — including those you’ve exposed above.
To correctly set permissions for an exposed device, first identify its major and minor numbers on the host (e.g., using ls -l /dev/<device>), then create a corresponding permission entry here.
SYSCTL & RLIMITS
Settings for sysctl fields and rlimits can be set as described in their associated man pages.
RootFS
This section has a single checkbox which gives the user a choice to make the containers filesystem read-only.
SECCOMP
Currently, seccomp is enabled on containers by default. To disable SECCOMP, a user must go to the container config > runtime settings and select the disable checkbox.
Host
The host section of the containers runtime config lists optional items that can be included which will interact with the underlying host the container is deployed to.
Expose Host's /Proc - Exposes underlying host's /proc directory to the container, which will be visible at /var/run/cycle/host/proc in the container. Toggling this setting off will remove the exposed filesystem from the host.
Expose Cgroup - Mounts the host's /sys/fs/cgroups directory into the container at /var/run/cycle/host/cgroups.
Power Management - Gives the container instances the permission to power off or reboot the host server via the internal api.
Privileges
These settings define exactly what privileges the container has on the host.
Namespaces - Namespaces define what is isolated in the container, and what is used on the host. The fewer namespaces a container has, the less secure it becomes. By default, a container has all namespaces enabled. At the least, they must have the MOUNT namespace. See here for detailed descriptions of the available namespaces.
Privileged Capabilities - Take granular control of specific kernel-level capabilities to a container for extra functionality. These can lead to interesting use cases, for example adding the CAP_NET_RAW capability, and building a containerized network monitoring dashboard. See here for detailed descriptions of the available kernel capabilities.
Fully Privileged - This gives the container full permissions on the host, tread carefully.