Skip to content
JelinaJelina DocumentationTechnical documentation
Back to website

Containerized applications

JelinaOS includes a complete container runtime, Docker, but container deployment follows one principle: manage applications through Releases instead of manually running containers on devices. We recommend using releases for every production container application to keep definition, deployment, supervision, updates, and rollback under control.

Section titled “Deployment workflow (recommended)”
Build and push image → Declare container application in Release → Deploy to device → Agent pulls and runs it

Step 1: Prepare the image

Section titled “Step 1: Prepare the image”

Build the application as a container image and push it to a private enterprise or public registry:

Terminal window
docker build -t registry.example.com/myapp:1.0.0 .
docker push registry.example.com/myapp:1.0.0

Step 2: Declare it in a release

Section titled “Step 2: Declare it in a release”

Create a release in JelinaCloud and add the container application:

  • Specify the image address and version tag; use an explicit version to avoid unintended upgrades.
  • Configure environment variables, port mappings, and volumes.
  • Set a restart policy, preferably always, and resource limits.

Step 3: Deploy

Section titled “Step 3: Deploy”

Deploy the release to a target fleet or device. The device agent automatically:

  • Pulls the image and creates the container.
  • Injects environment variables, maps ports, and mounts volumes according to configuration.
  • Starts and supervises the container, restarting it on abnormal exits and restoring it after device restarts.

Data persistence

Section titled “Data persistence”

The container filesystem is lost when a container is recreated. Mount data that must persist on the data partition:

  • Declare application volumes in the release, or mount directories from the device’s data partition.
  • Data remains independent of the container lifecycle and is unaffected by upgrades or recreation.

Inspection and diagnostics

Section titled “Inspection and diagnostics”

Docker commands on the device are intended for inspection and diagnostics, not deployment management:

Terminal window
docker ps                     # View container status
docker logs <container-name>           # View container logs
docker events                 # Track container events for diagnostics

Production practices

Section titled “Production practices”
  • Pin versions: Use explicit image version tags in releases.
  • Health checks: Configure service health checks with restart policies for automatic recovery.
  • Resource limits: Set container memory and CPU limits to avoid affecting the device as a whole.
  • Private registries: Use private image registries in enterprise environments; image distribution is centrally handled by the device agent.
  • Upgrades and rollback: Upgrade by publishing a new version and roll back by selecting the original version again; both are orchestrated in the cloud.

Common questions

Section titled “Common questions”

Can I deploy an application directly with docker run on the device? It is technically possible but not recommended. Applications run directly are outside the release system and lack centralized supervision, updates, and rollback. Use releases for production deployments.

What happens if a container exits abnormally? Applications configured with restart: always in the release are automatically restarted by the device agent.

Section titled “Related documentation”