Registry backends
Your artifacts — containers and packaged models — live in registries you already operate. Meshanics connects to them rather than asking you to move anything. The control plane authenticates to your upstream registry; devices then pull the bytes through a narrow, read-only facade, and verify everything against their pinned trust anchor before it is applied.
Supported registries
Connections are typed by how the platform obtains credentials:
| Provider | Registries | How it authenticates |
|---|---|---|
| Static | JFrog Artifactory, Harbor, GHCR, Quay, Azure Container Registry, Docker Hub, any standard registry | A stored username and token, or anonymous for a public registry |
| Google service account | Google Artifact Registry / GCR | Exchanges a stored service-account key for a short-lived OAuth2 access token at pull time |
| AWS ECR | Amazon Elastic Container Registry | Assumes a cross-account role you grant and exchanges it for a short-lived authorization token |
For the cloud providers, the platform holds a configuration rather than a long-lived password: a Google service-account key, or, for ECR, a role you let it assume (optionally with an external ID). Short-lived tokens are fetched on demand and cached per host until shortly before they expire, so a pull does not re-hit the token endpoint every time.
How credentials are handled
Stored tokens and provider configs are encrypted at rest. The platform's read views expose the host, the username, the provider type, and who connected it — never the secret. A connection with neither username nor token is treated as an anonymous public registry, and even that must be explicitly approved by an operator before the facade will proxy it.
The pull-through facade
Devices never receive a registry password. Instead they fetch through a device-facing, read-only facade, behind mutual TLS, that serves only digest references — manifests and blobs addressed by their content hash. The facade will proxy a host only if an operator has connected it, which contains the request surface, and it moves bytes only; it never decides what a device pulls. That decision belongs to the update metadata your device verifies independently.
This division is the point: the registry facade is plumbing, and trust comes from verification on the device, not from the registry the bytes happened to come from.
Air-gap and on-prem
Because connections target registries you run, an entirely on-prem or air-gapped deployment works the same way: point a connection at your internal registry host. Nothing in the core artifact path depends on a specific cloud provider.