Deploy Applications

Deploy and manage containerized workloads on ALPON edge AI computers from the Sixfab Connect platform. This guide covers two deployment paths (Docker Hub and the private Sixfab Container Registry), container access, lifecycle management, log streaming, and CI/CD patterns for production fleets.

Overview

ALPON treats every workload as an isolated Docker container. The runtime is preinstalled on the 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 is streamed back to the cloud in real time.

• No SSH or VPN required for deployment. The 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 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

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

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.

Click to enlarge

Click to enlarge

Click to enlarge

• 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

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.

Click to enlarge

Once deployed, the container appears in the Applications list with its status and resource usage.

Click to enlarge

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 system for securely storing and managing container images, hosted at cr.sixfab.io. Images are organized into repositories scoped to your account and pulled automatically by every ALPON device you own.

Registry overview

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

Click to enlarge

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

Set your registry password

Open Sixfab Registry in Connect. Your username is the 6-digit number visible at the top of the Registry page.

Click to enlarge

Click Reset Password on the Registry page. The password is shown once; copy and store it in a secrets manager.

Click to enlarge

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

Log in to the registry

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

bash

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

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

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

If you are on Windows or macOS with Docker Desktop, Buildx is preinstalled. On Linux, verify with docker buildx version.

4

Tag the image with the registry path

Tag the image so Docker knows where to push it. The path format is cr.sixfab.io/[username]/[image]:[tag].

bash

docker tag my-app:latest cr.sixfab.io/719663/my-app:latest

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/719663/my-app:latest

Expected output OK

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

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 to enlarge

Click Details on a repository to inspect its tags, digests, and per-tag usage.

Click to enlarge

Drill into a tag to view the full manifest, architecture, and runtime Config (entrypoint, command, working directory, exposed ports).

Click to enlarge

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.

Click to enlarge

Pick a port within 30000-32767 (e.g. 30900 if 30800 is already in use), review the configuration, and click + Deploy.

Click to enlarge

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, there are three ways to reach it 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.

Click to enlarge

# Replace [DEVICE_IP] with the value from the Network tab
http://[DEVICE_IP]:30800

Click to enlarge

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.

Click to enlarge

# 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>...

Click to enlarge

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.

Click to enlarge

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 & Debugging

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).

# Inspect environment
env | grep -i DATABASE

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

# 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.

# List running containers on the device
docker ps

# Inspect a specific container's runtime config
docker inspect <container-name>

# 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.

Related guides