Documentation

Learn the concepts and tools behind Pod-OS

Socket Deployment Types

Pod-OS runs a Socket Actor's software for you. There are two deployment types, and they differ in who builds the artifact and how Pod-OS starts it. Both are configured under GitHub / GitLab Integration when you deploy a new Gateway (Deploy Actor Network) or add an Actor to an existing Gateway (Add Actor).

Deployment type You provide Pod-OS does Best for
Self-registering container A Docker image built and pushed by CI (e.g. GitHub Actions → GHCR) Pulls the image and runs it, injecting Gateway connection details as environment variables Apps already packaged as containers
Gateway starts software A Git repo containing a runnable binary or script Clones the repo into the pod (optionally builds), then runs your command or startup script Scripts and self-built binaries; no container pipeline needed

Both types end up doing the same two things at runtime—register with the Gateway and answer health probes (StatusRequestStatus)—and both keep :62312 open for the Kubernetes readiness probe. The choice is only about packaging.

Reference examples (public repositories)

Pod-OS publishes a minimal, production-shaped reference repository for each type. Clone them, deploy them straight from the dashboard, or use them as templates:

Deployment type Repository Published artifact
Self-registering container PointOfData/podos-socket-self-register GHCR image ghcr.io/pointofdata/podos-socket-self-register
Gateway starts software PointOfData/podos-socket-gateway-starts Committed static bin/listener binary
Gateway starts software (matrix) examples/socket-git-ci/gateway-starts-matrix in this repo 3×4 config × language examples (path / build / inline × Go/Rust/Python/Java)

Each README includes build steps, the exact dashboard field values, and podos CLI verification commands. The gateway-starts-matrix covers Startup Script Path, Build Command, and inline Startup Script for Go, Rust, Python, and Java — with local and production test steps in each cell.


Type 1: Self-registering container

Use this when CI builds a Docker image and pushes it to a registry such as GitHub Container Registry (ghcr.io).

How it works

CI (GitHub Actions) builds Dockerfile → pushes ghcr.io/<org>/<repo>:main
  └─ Pod-OS pulls the image and runs it, injecting PODOS_* env vars
       └─ your process listens on :62312   (Kubernetes tcpSocket readiness)
       └─ SDK client dials the Gateway and registers as a Socket Actor
            └─ RespondToHealthChecks(client)  (answers StatusRequest)

Pod-OS passes Gateway connection details to your container as environment variables:

Variable Description
PODOS_GATEWAY_HOST Gateway hostname (for example, mygateway-lb)
PODOS_GATEWAY_PORT Gateway port (default 62312)
PODOS_ACTOR_NAME The Actor name you chose in the dashboard
PODOS_GATEWAY_FQN Fully qualified Gateway domain name

The SDK reads these for you via config.ConfigFromEnv().

Dashboard configuration

  • Integration Category: Self-registering container (image from CI)
  • Repository URL: https://github.com/<org>/<repo>
  • Branch / Tag: main (or the tag your CI publishes)
  • Container Image Override (recommended): the lowercase GHCR path, e.g. ghcr.io/<org>/<repo>:main

If the image is private, enable the image-pull-secret option and supply a GitHub username plus a Personal Access Token with read:packages.

Registry paths are lowercase. GitHub org/repo names may be mixed case, but the published image path is always lowercase (ghcr.io/pointofdata/...). The reference workflow lowercases this for you. If no package appears after a push, check the repo Actions tab—a repository name must be lowercase error means nothing was pushed.


Type 2: Gateway starts software

Use this when your Actor runs as a process the Gateway starts—not as a prebuilt container you register yourself. Pod-OS clones your Git repository into the pod before the Actor starts.

This mode runs executables or scripts only. You cannot start a separate container image this way.

How it works

Pod startup
  └─ Pod-OS clones your repo → /workspace/repo
       └─ (optional) runs your Build Command
            └─ runs your Command Path / Startup Script
                 └─ your process listens on :62312 and registers with the Gateway
                      └─ RespondToHealthChecks(client)  (answers StatusRequest)

The default runtime image has bash and the Pod-OS binaries only—no language toolchain at runtime.

For Python or Java scripts, select a platform Runtime flavor in the dashboard. Flavor images extend the actor base with the language and the matching official SDK:

Runtime Image (local) SDK Use when
Default pod-os/actor:<ver> Go/Rust static binaries committed to the repo
Python pod-os/actor-python:<ver> pod-os-py-client Python startup scripts
Java pod-os/actor-java:<ver> pod-os-java-client Java entrypoints on the platform classpath

Go and Rust SDKs are compile-time: use Default and commit a static binary (as the Go reference repo does), or use Type 1 with a custom image. Heavy custom dependencies still belong in Type 1 (FROM a flavor image in your own Dockerfile).

Dashboard configuration

  • Integration Category: Gateway starts software (clone repo)
  • Runtime: Default, Python, or Java (Socket actors)
  • Repository URL: https://github.com/<org>/<repo>
  • Branch / Tag: main
  • Clone Path: /workspace/repo (default)
  • Command Path / Startup Script Path: the runnable entry point after clone, e.g. /workspace/repo/path/go/bin/start.sh (full 3×4 matrix: examples/socket-git-ci/gateway-starts-matrix/ in this repo)
  • Build Command (optional): e.g. cd /workspace/repo/build-command/python && pip install --break-system-packages -r requirements.txt
  • Startup Script (inline) (optional): bash script content stored in a Kubernetes secret when you do not commit bin/start.sh to the repo

Private repositories require a Personal Access Token with repository Contents: Read. Pod-OS stores it in a Kubernetes secret used only by the git-clone init container.


Picking up changes after deploy

After the initial deploy, use the right control depending on what changed:

What changed Action
New CI image at the same tag (e.g. :main) Source sync → Pull latest image on the actor edit form
New commits on the tracked branch/tag (Type 2) Source sync → Reclone repository on the actor edit form
Platform runtime image bump (Type 2 Default/Python/Java base) Update to current platform image on the actor edit form
Compute fields (CPU, repo URL, branch, startup script, etc.) Save Changes on the actor edit form

Source sync (POST /actors/:id/source-sync) force-pulls the configured container image (Type 1, with imagePullPolicy: Always) or reclones the configured git ref (Type 2) and restarts the pod. It does not change dashboard configuration — only refreshes what is already configured.

Save Changes always redeploys shell/socket actors and persists form updates to the compute record. For Type 1 actors tracking a mutable tag like :main, use Source sync when CI publishes a new image without changing the tag.

Update to current platform image applies only to platform-managed runtime images (Type 2). It does not apply to Type 1 custom CI images.


Choosing between them

Your software is… Choose
Already built into a Docker image by CI Self-registering container
A binary or script you can commit and run directly Gateway starts software
Compiled, and you'd rather build in CI than in the pod Self-registering container
A Python or Java script using the official SDK Gateway starts software + matching Runtime flavor
A quick Go/Rust binary with no container pipeline Gateway starts software + Default runtime

For a field-by-field deployment walkthrough (PAT scopes, dashboard options, troubleshooting), see Deploy Actors with GitHub.

Verifying health

From inside the cluster, dial the Gateway load balancer (<gateway>-lb:62312) and probe the Actor with the podos CLI:

# A Socket (non-Neural-Memory) Actor should NOT answer NM queries (times out / errors):
podos send --actor mysocket@mygw.pod-os.com --intent GetEventsForTags --data "health_check=test"

# Once RespondToHealthChecks is live, the status probe returns Status:
podos send --actor mysocket@mygw.pod-os.com --intent StatusRequest

Use the load-balancer socket directly; the AIP binary handshake does not survive kubectl port-forward. For a full walkthrough of using podos during development, see Testing Code Paths with podos.


Next: What is an Evolutionary Neural Memory? — the built-in Actor that stores and connects your data.