Skip to main content

Security

Credentials Never Leave Your Machine​

anycloud runs entirely on your machine. Your cloud credentials are:

  • Stored locally in a SQLite database at ~/.anycloud/api.db, managed by the local anycloud API container
  • Encrypted at rest using libsodium (XSalsa20-Poly1305)
  • Never sent to any external service — anycloud talks directly to your cloud provider

The encryption key (~/.anycloud/cipher.key) is generated locally and never transmitted.

Secrets​

Named secrets (anycloud secrets new|list|delete) follow the same storage model as credentials: encrypted at rest in the local SQLite database using libsodium, never transmitted to any external service. Secrets differ from --env values in two ways:

  • Write-only via the API. The create route accepts values; list returns only names and timestamps; there is no route that returns values. --env values, by contrast, are visible in API responses.
  • Rotatable by name. Updating a secret and resubmitting re-injects the new value into the next VM. Running containers keep their already-injected values until their VM terminates; spot-preemption recovery starts a new VM and re-reads the store, so rotated or force-deleted values propagate there. secrets delete is blocked by default while a non-terminal deployment still references the name.

At VM provisioning, resolved values are written to /run/anycloud-secrets.env (tmpfs, mode 0600, root-owned) and passed to the container via docker run --env-file. Any --env KEY=VALUE explicitly set on submit overrides a same-named key coming from a secret.

Docker inlines --env-file values into the container's run config, so anyone with root on the VM can still read them from docker inspect or /proc/<pid>/environ — the same reality as any env-passed value. The primitive protects secrets from the API surface and from plaintext storage, not from a VM-root attacker.

SSH Keys​

Every deployment gets a unique ED25519 SSH keypair:

  • Generated locally on your machine
  • Private key stored at ~/.anycloud/.ssh/{deployment-id} (mode 0600)
  • Public key is placed on the VM for SSH access
  • Keys are unique per deployment — no shared keys

Authentication​

anycloud login authenticates via GitHub OAuth. The token is stored locally at ~/.anycloud/.token and used for two things:

  1. Pulling private images from GitHub Container Registry (GHCR). Public images from any registry work without authentication.
  2. Git-based code sync for the @anycloud.function() decorator (see below).

No passwords are stored.

Git-Based Code Sync​

The @anycloud.function() decorator clones your GitHub repository on the remote VM. To authenticate:

  • Your GitHub token (from ~/.anycloud/.token) is passed as the GITHUB_TOKEN environment variable inside the container
  • The token is used to git clone your repo — required for private repositories
  • Code is cloned at the exact commit SHA you submitted from

The token is available inside the container for the duration of the job. If your code doesn't need GitHub access beyond the initial clone, you can unset it in your function.

VM Security​

  • VMs are provisioned in your own cloud account
  • SSH access is restricted to your generated keypair
  • Cloud-native IAM roles are used for same-cloud bucket access (no credentials on VMs)
  • Cross-cloud S3 bucket sync uses scoped STS credentials written to root-only rclone env files on the VM; these tokens expire after 36 hours and are not refreshed mid-run
  • Each deployment is isolated with its own VM, SSH key, and IAM role