Video walkthrough

Watch the two-part screen recording for an end-to-end walkthrough of the workflow on ALPON. Click any timestamp to jump to that section of the video.

— Part 1 · ~3:30

How to containerize apps for ALPON devices

Build an ARM64 Docker image on your workstation, log in to the Sixfab Container Registry at cr.sixfab.io, and push the image so it's ready to deploy to any ALPON device. Click a chapter to jump to that section in the video.

Chapter timestamps

• 00:00Introduction
• 00:15Docker Desktop
• 00:31Setting up project folder
• 00:44Creating Python script
• 01:03Requirements file
• 01:17.dockerignore file
• 01:27Writing the Dockerfile
• 02:02Building the image
• 02:18Testing the container locally
• 02:23Registry setup & login
• 02:42Tagging the image
• 02:58Pushing to Sixfab Registry
• 03:13Verification & conclusion

— Part 2 · ~3:00

How to deploy & update apps remotely

Deploy the pushed image to an ALPON device from Sixfab Connect, configure ports, environment variables, volumes, and security toggles, then manage the running container — including rolling back updates remotely. Click a chapter to jump to that section in the video.

Chapter timestamps

• 00:00Introduction & recap
• 00:16Reliability & network failover
• 00:36Navigating to application deployment
• 00:55Selecting custom images from Registry
• 01:10Config: env, ports & volumes
• 01:23Security: host network & privileged
• 01:57Deploying & status monitoring
• 02:12Remote management
• 02:27Rolling back updates
• 02:46Conclusion

Overview

ALPON treats every workload as an isolated Docker container. The runtime is preinstalled on each device and authenticated against the Sixfab Container Registry out of the box, so deployment is a one-click operation from the cloud dashboard. There is no SSH-based provisioning, no manual docker pull, and no per-device credential management.

What you can deploy

How deployment works

Every ALPON device opens a persistent connection to the Sixfab Connect control plane. When a deploy is triggered from the dashboard, the platform sends a structured manifest to the device, which then pulls the image, applies port and volume mappings, and starts the container. Status streams back to the cloud in real time.

• No SSH or VPN required for deployment. Each device pulls images over its existing outbound TLS connection.
• Tenant-isolated. Each device pulls only from its owner's repositories and from official Sixfab images.
• Lifecycle from the cloud. Start, pause, restart, edit, delete, and stream logs without ever touching the device.
• Multiple containers per device. Run as many workloads as the device's CPU, RAM, and storage allow.

Deployment methods

ALPON supports two image sources. Both deploy through the same Applications tab on Sixfab Connect; the difference is where the image lives.

Deploying from Docker Hub

The fastest way to run a container on ALPON. The example below deploys nginx; the same flow applies to any ARM64-compatible image.

1. 1

   Open the Applications tab

   Log in to connect.sixfab.com, open Assets, select your registered ALPON device, then switch to the Applications tab. Click + Deploy to open the configuration panel.

2. 2

   Configure the container

   Fill in the deployment form. The minimum required fields are Container Name, Image, and at least one Port mapping if the container exposes a service.

   

   • Container Name: a descriptive identifier (e.g. my-nginx).
   • Image: check "I would like to use my own container path" and enter the Docker Hub image, e.g. nginx:latest or redis:7-alpine.
   • Ports: map device ports to container ports (e.g. host 30800 → container 80). Host ports must be in 30000–32767.
   • Environment, Volumes, Host Network, Privileged: see Configuration reference for full semantics.

   

   

3. 3

   Deploy

   Review the form and click + Deploy. The device pulls the image and starts the container; status flips to Running in the Applications list once the container is live.

   

   

   First pull may take a minute

   Initial pulls over cellular links can be slow for large images. After the first pull the image is cached on the device; subsequent restarts are instant.

Sixfab Container Registry

The Sixfab Container Registry is a private OCI-compatible registry hosted at cr.sixfab.io, scoped to your account. ALPON devices auto-authenticate against it and pull from your repositories and from official Sixfab images.

Registry overview

The Registry is accessible from Developer Tools → Registry in Sixfab Connect. It shows each repository with size, creation date, and quota usage.

Push an image to the Registry

Run the following commands on your build machine (laptop, server, or CI runner) to push a local image to your registry namespace.

1. 1

   Set the registry password

   Open Sixfab Registry and click Reset Password. The password is shown once; copy and store it in a secrets manager. Your username is the 6-digit number visible at the top of the Registry page.

   

   

   Save the password immediately

   Registry credentials are independent from your Sixfab Connect account login. If lost, the only recovery is to issue a new password via Reset Password, which invalidates the previous one.

2. 2

   Log in to the registry

   Authenticate Docker against cr.sixfab.io. Replace <your_username> with your own 6-digit registry username.

   bash

   # 1. Authenticate Docker to the Sixfab Container Registry
   docker login cr.sixfab.io --username <your_username>
   # Password: paste the registry password (input is hidden)

3. 3

   Build for ARM64

   Build the image with Docker Buildx, targeting linux/arm64. The --load flag makes the resulting image available locally so you can tag and push it.

   bash

   # 1. From the directory containing your Dockerfile
   docker buildx build --load --platform linux/arm64   -t my-app:latest .

   Buildx availability

   Docker Buildx is preinstalled on Windows and macOS with Docker Desktop. On Linux, verify with docker buildx version before running the command above.

4. 4

   Tag with the registry path

   Tag the image so Docker knows where to push it. The path format is cr.sixfab.io/<your_username>/<image>:<tag>.

   bash

   docker tag my-app:latest cr.sixfab.io/<your_username>/my-app:latest

5. 5

   Push the image

   Upload the image to your private repository. Layer caching means subsequent pushes only transfer changed layers.

   bash

   docker push cr.sixfab.io/<your_username>/my-app:latest
   
   # The push refers to repository [cr.sixfab.io/719663/my-app]
   571fd9f78ac9: Pushed
   latest: digest: sha256:2aeab3830f8eaf2775fd599fda6a516a95c1480239ba5e64a632a68c1f3bd53d
   size: 29.31 MB

6. 6

   Verify in the Registry

   Refresh the Registry page on Connect. The new image appears in the repository list with size, creation date, and last-update timestamp. Click Details on a repository to inspect tags, digests, and the underlying manifest. Each tag shows a See Usage button to identify which devices run it. Drilling into a tag reveals the full manifest, architecture (arm64), OS (linux), runtime Config, and layer-level breakdown.

7. 7

   Deploy from the Registry

   Open the device's Applications tab and click + Deploy. In the Image field, leave the custom-path checkbox unchecked to pick from your registry dropdown. Select the image and tag, configure ports and environment, then deploy.

   

   

Configuration reference

Every field exposed in the deployment form, with semantics and constraints.

Port range explained

ALPON exposes container services on host ports in the 30000–32767 range. This range is firewalled to allow inbound traffic from the local network and from Sixfab Connect's remote-access tunnels. Ports outside this range are reserved for the operating system, the Sixfab agent, and cellular telemetry.

Access the container

Once a container is running, three options are available depending on your network position relative to the device.

Access from the local network

Find the device's IP on the Network tab of the Asset Detail page, then open a browser on any machine in the same network.

# Replace <device_ip> with the value from the Network tab
http://<device_ip>:30800

Access via the remote terminal

If the device is offsite or behind NAT, open the Device tab and click Open Remote Terminal. The terminal session runs on the device itself, so 127.0.0.1 resolves to the device.

# 1. Verify the container is reachable on the device itself
curl http://127.0.0.1:30800
# <!DOCTYPE html>
# <html>
# <head><title>Welcome to nginx!</title>...

Access via a connected display

Connect a monitor to the device, open a browser locally, and navigate to http://127.0.0.1:30800. Suitable for digital signage, kiosk dashboards, and on-device debugging.

Manage & lifecycle

Every running container exposes lifecycle controls in the Applications tab. Operations are issued from the cloud and applied on the device within seconds.

Updating to a new image version

Two patterns work, depending on how you tag releases:

1. Mutable tag (:latest): push a new image with the same tag, then click Restart. The device pulls the new digest and recreates the container.
2. Immutable tag (:v1.2.3): push a new tag, click Edit Deployment on the running container, change the image tag, and save. Recommended for production traceability.

Logs & debug

Containerized applications write to stdout and stderr; ALPON captures both streams and exposes them in the dashboard. For deeper inspection, use the in-container terminal.

Stream logs from the dashboard

On the Applications tab, click Logs next to the container. The view tails the last 1000 lines and streams new output in real time. Use it to confirm startup, watch request traffic, or catch crash loops.

Inspect a running container

Open the Container Terminal from the dashboard to drop into an interactive shell. The session uses the image's default shell (typically /bin/sh for Alpine, /bin/bash for Debian-based images).

# 1. Inspect environment
env | grep -i DATABASE

# 2. Tail application log files written inside the container
tail -f /var/log/app.log

# 3. Check listening ports
netstat -tlnp 2>/dev/null || ss -tlnp

Use the device terminal for Docker-level operations

The container terminal runs inside the container. To inspect Docker itself (image cache, volumes, networks), open the Remote Terminal on the Device tab.

# 1. List running containers on the device
docker ps

# 2. Inspect a specific container's runtime config
docker inspect <container_name>

# 3. View resource usage live
docker stats

CI/CD integration

The Sixfab Container Registry is a standard OCI registry, so any CI system that can run Docker can build and push to it. Below is a complete GitHub Actions workflow that builds for ARM64 and pushes on every tagged release.

GitHub Actions: build & push to Sixfab Registry

Store the registry password in repository secrets as SIXFAB_REGISTRY_PASSWORD and your username as SIXFAB_REGISTRY_USERNAME.

name: Build and push to Sixfab Registry

on:
  push:
    tags: ['v*']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to Sixfab Registry
        uses: docker/login-action@v3
        with:
          registry: cr.sixfab.io
          username: ${{ secrets.SIXFAB_REGISTRY_USERNAME }}
          password: ${{ secrets.SIXFAB_REGISTRY_PASSWORD }}

      - name: Build and push (linux/arm64)
        uses: docker/build-push-action@v5
        with:
          context: .
          platforms: linux/arm64
          push: true
          tags: |
            cr.sixfab.io/${{ secrets.SIXFAB_REGISTRY_USERNAME }}/my-app:${{ github.ref_name }}
            cr.sixfab.io/${{ secrets.SIXFAB_REGISTRY_USERNAME }}/my-app:latest

GitLab CI example

build_arm64:
  image: docker:24
  services: [docker:24-dind]
  variables:
    DOCKER_BUILDKIT: "1"
  before_script:
    - echo "$SIXFAB_REGISTRY_PASSWORD" | docker login cr.sixfab.io         -u "$SIXFAB_REGISTRY_USERNAME" --password-stdin
  script:
    - docker buildx create --use
    - docker buildx build --platform linux/arm64         -t cr.sixfab.io/$SIXFAB_REGISTRY_USERNAME/my-app:$CI_COMMIT_TAG         --push .

Triggering deployment from CI

Pushing a new tag does not automatically redeploy running containers. For automated rollout you have two choices:

• Edit Deployment from the dashboard after CI publishes the new tag. Suitable for staged or manual rollouts.
• Use mutable tags (:latest) plus the Restart action. CI overwrites :latest, then a separate step calls the Sixfab Connect API to restart the container, triggering a fresh pull. Sacrifices traceability for speed.

Troubleshooting

Common failure modes and their fixes.