Deploy Applications

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 ALPON Cloud, configure ports, environment variables, volumes, and security toggles, then manage the running container — including rolling back to a previous image tag. Click a chapter to jump to that section in the video. The rollback recipe is written up under Manage & lifecycle; connectivity and network-failover behaviour covered in the opening chapter is documented in ALPON Cloud.

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 driven entirely from the ALPON 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 ALPON Cloud 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.
• Scoped registry access. Each device authenticates only to its owner's repositories and to 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 in ALPON Cloud; 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, so later restarts reuse the cached image instead of downloading it again.

Sixfab Container Registry

The Sixfab Container Registry is a private OCI-compatible registry hosted at cr.sixfab.io, scoped to your account. ALPON devices authenticate against it automatically and pull from your own repositories and from official Sixfab images. This section is the canonical reference for registry quotas and credentials; other ALPON pages link here.

Registry overview

The Registry is accessible from Developer Tools → Registry in ALPON Cloud. 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 ALPON Cloud 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. On an x86 Linux host, also register the ARM emulator once with docker run --privileged --rm tonistiigi/binfmt --install arm64; without it, RUN steps in an arm64 build fail with exec format error.

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: 1786

6. 6

   Verify in the Registry

   Refresh the Registry page in ALPON Cloud. 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

The deployment form accepts host ports in the 30000–32767 range. Map the container's own port (unrestricted) to a host port in that range, then use the host port when you reach the service from the local network or from the device itself.

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 as soon as the device receives the command.

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.

Rolling back to a previous version

Rollback uses the same Edit Deployment path, pointed at an older tag that is still in the Registry:

1. Open Developer Tools → Registry, select the repository, and note the immutable tag of the last known-good build (e.g. :v1.2.2).
2. On the device's Applications tab, click Edit Deployment on the running container.
3. Change the image tag to that previous tag, leave the rest of the form unchanged, and save. The device pulls the older tag and recreates the container.
4. Open Logs and confirm the container reaches a healthy start.

This works only while the previous tag still exists and has not been overwritten, which is why every release should carry its own immutable tag.

Logs & debug

Containerized applications write to stdout and stderr; ALPON captures both streams and exposes them in the dashboard. For deeper inspection, open the container's Shell.

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's Shell from its detail view in the dashboard to drop into an interactive session. It 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 Shell session 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. Both examples below register the ARM emulator before building: hosted runners are x86_64, and an arm64 build without binfmt registered fails with exec format error.

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 QEMU (arm64 emulation)
        uses: docker/setup-qemu-action@v3
        with:
          platforms: arm64

      - 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
          # The moving :latest tag is optional. Keep it only if you use the Restart-based rollout below.

GitLab CI example

build_arm64:
  image: docker:24
  services: [docker:24-dind]
  before_script:
    - echo "$SIXFAB_REGISTRY_PASSWORD" | docker login cr.sixfab.io \
        -u "$SIXFAB_REGISTRY_USERNAME" --password-stdin
  script:
    - docker run --privileged --rm tonistiigi/binfmt --install arm64
    - 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 Restart the container from the device's Applications tab to force a fresh pull. That restart step is manual: there is no documented ALPON Cloud API endpoint for restarting a container. Sacrifices traceability for speed.

Troubleshooting

Common failure modes and their fixes.