Container Lifecycle
How Trustgrid containers start, stop, restart, and run on a schedule.
6 minute read
Trustgrid nodes can run container images built to the Docker/OCI image spec, which allows for ease of deployment across an organization. Containers run with least-privilege defaults; workloads that need elevated access can opt into specific Linux Capabilities or full Privileged mode. Container security covers the implications of each.
The container can be attached to both the local and virtual network space which allows both local and remote resources to communicate with the container. For example an API could be deployed on a Trustgrid Gateway which sends API Calls via the virtual network space to a container running on a Trustgrid Edge Node. The API call could then be translated to make a call to a database running on the local network and passed back up to the gateway host.
Before adding a container to a node, push an image to your repository. Pushes must be linux/amd64; supported image platforms covers the Apple-Silicon caveat.
Reading and managing containers requires node-exec::read and node-exec::modify permissions, respectively. Executing a container requires node-exec::compute permission.
Container configuration is set at the cluster level on a cluster, or at node scope on a standalone appliance. The runtime controls — Start, Stop, Logs, Terminal — are always at the node scope of the appliance running the container. The portal redirects you between these views as appropriate. See Container Tools for the full breakdown.
Navigate to Container Management under Compute on a node or cluster.

Available actions from the Actions menu:

| Field Name | Description |
|---|---|
| Name | The name of the container. |
| Description | Free-text description for the container. |
| Execution Type | Service, Recurring, or On Demand. Determines when and how often the container runs and whether it restarts on exit. See Container lifecycle. |
| Status | Only Enabled containers will run. |
| Image Name | The name of the image to execute, in the form <your-namespace>/<image>. |
| Image Tag | The image tag to execute. |
The overview section allows editing basic information about the container’s execution environment.

| Field Name | Description |
|---|---|
| Save Output | Persist standard output/standard error to the Trustgrid cloud for analysis. It is the customer’s responsibility to ensure no privileged information is included in the output. See Container security — Save Output. |
| Schedule | Cron expression or rate (e.g. rate(1 hour)) that governs when the container runs. Shown only when Execution Type is Recurring. See Container lifecycle — Recurring for the accepted formats. |
| Command | The command to execute inside the container. Replaces the image’s default command or arguments while preserving its entrypoint. Useful for troubleshooting. |
| Hostname | The hostname set inside the container. Defaults to the appliance’s name. |
| Stop Time | Grace period (in seconds) to allow a container to stop before killing it. Defaults to 30 seconds. |
| User | Sets the username/group/UID/GID the container’s main process runs as. See Container security — User. |
| DNS | DNS server for resolution inside the container. By default the container uses the appliance-side resolver at 172.18.1.2 which resolves other containers by name and forwards external lookups. See Container networking — DNS resolver. |
| IP | Pins the container to a specific IP in 172.18.0.0/16. By default the address is assigned dynamically. See Container networking — The container bridge. |
| Privileged | Grant the container extended privileges — disables most of the sandbox. Almost no workload should need this. Prefer Linux Capabilities. |
| Use Init | Run an init process as PID 1 inside the container. Recommended for any service that spawns child processes. See Container security — Use Init. |
| Require Connectivity | Gates container startup on the appliance having control-plane connectivity before its encrypted volumes can be mounted. See Container storage — Encrypted volumes. |
Environment variables can be added to a container to provide configuration at runtime.

Configure the container’s VRF, port mappings, virtual networks, and virtual interfaces. Conceptual background: Container networking.

Expose a port on the appliance to the container.
| Field Name | Description |
|---|---|
| Protocol | Protocol to listen for. Must be set explicitly to tcp or udp; blank values are ignored. |
| Host Interface | The appliance NIC to listen on (e.g. ens192). |
| Host Port | The host port to listen on. |
| Container Port | The container port that receives the mapped traffic. |
Attach a Trustgrid virtual network so peer nodes can reach the container.
| Field Name | Description |
|---|---|
| Virtual Network | The virtual network to attach. |
| Virtual IP | The virtual IP to assign to the container. |
| Allow Outbound | Whether the container may originate connections onto the virtual network. |
See Tutorial: expose a container over a virtual network.
Forward all traffic from an appliance-side virtual interface into the container as a dedicated interface.
| Field Name | Description |
|---|---|
| Name | The virtual interface name on the appliance. |
| Destination | The interface name presented inside the container. |
Persist data either as an externally defined volume, or a bind mount of the appliance’s filesystem. Conceptual background: Container storage.

| Field Name | Description |
|---|---|
| Type | BIND or VOLUME. For VOLUME, the source must reference an existing volume. |
| Source | For volumes, the volume name. For bind mounts, the absolute path on the appliance’s filesystem. |
| Destination | The mount location inside the container. |
When mounting an encrypted volume, the mount also exposes Require Connectivity. Enable it to block startup until the appliance can reach the control plane and unlock the volume. See Container storage - Encrypted volumes.
Restrict the resources a container can consume from the host.

| Field Name | Description |
|---|---|
| CPU Max % | Maximum CPU allocation. Default is 50%. |
| Memory Max (MB) | Hard RAM limit. Default is 50% of host memory. |
| Memory High (MB) | Soft RAM limit. Cannot exceed hard limit. Default is 45% of host memory. |
| IO Max Read (B/s) | Max IO read bytes/sec. Disabled by default. |
| IO Max Write (B/s) | Max IO write bytes/sec. Disabled by default. |
| IO Max Read Operations (ops/s) | Max IO read ops/sec. Disabled by default. |
| IO Max Write Operations (ops/s) | Max IO write ops/sec. Disabled by default. |
Linux ulimits can also be set per container. Supported ulimits: CORE, DATA, FSIZE, LOCKS, MEMLOCK, MSGQUEUE, NICE, NOFILE, NPROC, RSS, RTPRIO, RTTIME, SIGPENDING, STACK.
Configure a probe that monitors container health. A health check periodically runs a command inside the container and uses its exit code to mark the container Healthy or Unhealthy in the portal. It’s a reporting mechanism only — the container is not automatically restarted on failure.

| Field Name | Description |
|---|---|
| Command | Command to run. Non-zero exit means failure. |
| Interval | Seconds between checks. |
| Timeout | Seconds to wait for a check; timeout counts as failure. |
| Start Period | Grace seconds during container startup before checks begin. |
| Retries | Failures allowed before marking the container unhealthy. |
Add or drop specific Linux capabilities. Always prefer this over enabling Privileged. See Container security — Linux Capabilities.

Rotate persisted container logs (when Save Output is enabled).

| Field Name | Description |
|---|---|
| Max File Size (MB) | Maximum log file size before rotation. |
| Max Files | Maximum number of rotated log files to keep. |
How Trustgrid containers start, stop, restart, and run on a schedule.
How to give a container persistent storage or access to host files.
Operate running containers — start, stop, view logs, and open a shell from the portal.
Manage container images stored on nodes
Configure volumes on nodes for use by containers for persistent storage
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.