[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/hashtag",{"_7":8,"_9":10,"_11":12},"articles",[13],"authors",{},"tag","decentralised-cloud",{"_14":15,"_16":17,"_18":19,"_20":21,"_22":23,"_24":25,"_26":27},"content","# Deploying to Akash with a Multi Agent Team and Private Container Registries\n\n## Summary\n\nA walkthrough of deploying a containerised application to the Akash Network using a Hermes multi agent system powered by AkashML AI models. Covers the full lifecycle from Dockerfile to a live deployment on decentralised infrastructure, including the `deploy akash` skill and the private container registry pattern.\n\n## What Is Akash?\n\nAkash is an open source decentralised cloud computing marketplace. Unlike traditional cloud providers that run on centralised data centres, Akash aggregates idle compute capacity from a global network of providers. Workloads are deployed via a peer to peer marketplace where bids compete on price, giving users access to compute at a fraction of AWS, GCP, or Azure rates.\n\nKey properties that make Akash unique:\n\n* **Permissionless**: Anyone with a wallet can deploy. No accounts, no credit cards, no support tickets.\n* **Censorship-resistant**: Your workload runs on independent providers around the world, not inside a single corporate data centre.\n* **Cost competitive**: Competitive bidding drives prices down. You specify your maximum price; providers undercut each other to win the lease.\n* **Kubernetes native**: Deployments use the SDL (Stack Definition Language), which compiles down to Kubernetes manifests. If you can write a Docker Compose file, you can write an SDL.\n* **Community governed**: Protocol parameters, software upgrades, and economic policy are decided by AKT token holders.\n\nAkash operates as a live decentralised compute marketplace with active providers and production workloads. Akash represents one approach to decentralised infrastructure and marketplace driven compute.\n\n## The Problem\n\nYou have a containerised application , a static site, an API service, a dashboard , and you want it running on Akash. You also want it built in CI, pushed to a private registry, and deployed automatically. Sounds straightforward, right?\n\nThis is exactly where a multi agent collaboration system proves its value. Instead of one person grinding through these interconnected issues, specialised agents work in parallel , each tackling their domain , while a coordinator validates the integrated result.\n\n## The Architecture: Hermes with AkashML Models\n\nThe system uses three agent roles, all powered by AkashML AI models:\n\n* **Coordinator Agent**: Authors content, assigns tasks, validates results, and manages the overall workflow.\n* **Implementation Worker**: Handles Dockerfile, CI pipeline configuration, and deployment scripts. Writes code that compiles and runs.\n* **Review Worker**: Critiques architecture, flags security risks, identifies weak assumptions, and validates operational concerns.\n\nThese agents operate from a **shared project workspace** , a durable filesystem where artifacts are committed, versioned, and shared. Agent outputs are not ephemeral chat messages; they are files in a Git repository.\n\n## The `deploy akash` Skill\n\nThe workflow described here is codified into a reusable Hermes skill: `deploy akash`. A skill is a procedural playbook that agents consult when they encounter a recurring task. It is not black box automation , it is a documented, versioned, and reviewed by peers guide that any agent can follow, inspect, or improve.\n\nThe `deploy akash` skill encodes the following safety rules and workflow:\n\n* **Managed wallet API only**: Agents authenticate with Akash via the Akash Console REST API using a single API key header (`x-api-key`). No self custody keys, no mnemonics, no local keyring files. This keeps the deployment flow stateless and safe to run inside CI.\n* **Private registry prerequisite**: Before any deployment, the worker must verify that a deployable container image exists. If no public image is available, the pipeline must provide registry credentials via CI environment variables , never committed to the repository.\n* **SDL templating**: The SDL file in the repository uses angle-bracket placeholders (``, ``) that are substituted at deploy time by a shell script. This separation of template from runtime data keeps secrets out of version control.\n* **Bid polling with timeout**: The deployment script polls the Akash marketplace for bids, selects the cheapest provider, and creates a lease automatically. If no bids arrive within a configurable window, the deployment fails fast rather than hanging.\n* **Teardown instructions**: Every deployment skill must document how to close the lease. On Akash, open leases continue to charge the escrow deposit until closed or exhausted.\n* **Error catalogue**: Documented failure modes include \"zero bids\" (pricing too low, `signedBy` too restrictive), \"invalid manifest\" (SDL schema error), \"pull failure\" (registry credentials missing or incorrect), and \"timeout\" (provider did not start within the polling window).\n\nWhen an agent is tasked with an Akash deployment, it loads this skill, follows the checklist, and produces a reproducible result. If a new failure mode is discovered, the skill is patched and all future agents inherit the fix.\n\n## Step 1: The Container Image\n\nThe Implementation Worker starts by writing a minimal Dockerfile:\n\n```dockerfile\nFROM nginx:alpine\nCOPY index.html /usr/share/nginx/html/index.html\nEXPOSE 80\n```\n\nSimple, correct, secure. The Review Worker confirms `nginx:alpine` is a reasonable base and that no secrets are baked into the image.\n\nThe Dockerfile is committed to the repository along with a CI pipeline that builds and pushes the image on every commit. The pipeline uses Docker in Docker and tags the image with the Git commit SHA for reproducibility, avoiding the trap of mutable `:latest` tags in production deployments.\n\nA generic CI pipeline for this looks like:\n\n```yaml\nstages:\n - build\n - deploy\n\nvariables:\n DOCKER_DRIVER: overlay2\n DOCKER_TLS_CERTDIR: \"\"\n REGISTRY: your-registry.example.com\n IMAGE_NAME: your-app\n\nbuild:\n stage: build\n image: docker:24-dind\n services:\n - docker:24-dind\n script:\n - docker login -u \"$REGISTRY_USER\" -p \"$REGISTRY_PASSWORD\" \"$REGISTRY\"\n - docker build -t \"$REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA\" .\n - docker push \"$REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA\"\n\ndeploy:\n stage: deploy\n image: alpine/curl:latest\n script:\n - ./deploy.sh\n```\n\nThis is vendor agnostic Docker in Docker. It works in GitLab CI, GitHub Actions with DinD runners, Drone, Woodpecker, or any CI system that supports service sidecars and Docker CLI access.\n\n## Step 2: The SDL and the First Failure\n\nThe Review Worker authors the initial Akash SDL (Stack Definition Language) manifest:\n\n```yaml\n---\nversion: \"2.0\"\n\nservices:\n web:\n image: your-registry.example.com/your-app:latest\n credentials:\n host: your-registry.example.com\n username: \"\"\n password: \"\"\n expose:\n - port: 80\n as: 80\n to:\n - global: true\n\nprofiles:\n compute:\n web:\n resources:\n cpu:\n units: 0.1\n memory:\n size: 128Mi\n storage:\n - size: 512Mi\n\n placement:\n akash:\n signedBy:\n anyOf:\n - akash1365yvmc4s7awdyj3n2sav7xfx76adc6dnmlx63\n - akash18qa2a2ltfyvkyj0zgj6vzp3gdejwkpqwcwcwrr\n pricing:\n web:\n denom: uakt\n amount: 1000\n\ndeployment:\n web:\n akash:\n profile: web\n count: 1\n```\n\nThe credentials use angle-bracket placeholders (``, ``). At deploy time, a script substitutes these with values from CI/CD secrets. This keeps credentials out of the Git history.\n\nThe `deploy.sh` script templates the SDL and submits it to Akash:\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\n# Template the SDL — substitute placeholders with CI secrets\nSDL=$(cat deploy.yml | sed \\\n -e \"s||${REGISTRY_USER}|g\" \\\n -e \"s||${REGISTRY_PASS}|g\" \\\n -e \"s|:latest|:${BUILD_VERSION}|g\")\n\n# Create deployment\nRESPONSE=$(curl -fsS -X POST https://console-api.akash.network/v1/deployments \\\n -H \"x-api-key: ${AKASH_API_KEY}\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"data\\\":{\\\"sdl\\\":$(echo \"$SDL\" | jq -Rs .),\\\"deposit\\\":5.5}}\")\n\nDSEQ=$(echo \"$RESPONSE\" | jq -r '.data.deployment_id.dseq')\necho \"Deployment created: DSEQ=$DSEQ\"\n\n# Poll for bids\necho \"Waiting for bids...\"\nfor i in $(seq 1 30); do\n BIDS=$(curl -fsS \"https://console-api.akash.network/v1/bids/$DSEQ\" \\\n -H \"x-api-key: ${AKASH_API_KEY}\")\n COUNT=$(echo \"$BIDS\" | jq '.data | length')\n if [ \"$COUNT\" -gt 0 ]; then\n echo \"Bids received: $COUNT\"\n break\n fi\n sleep 3\ndone\n\n# Select cheapest provider\nPROVIDER=$(echo \"$BIDS\" | jq -r '.data | sort_by(.bid.price.amount) | .[0].bid.id.provider')\necho \"Selected provider: $PROVIDER\"\n\n# Create lease\nMANIFEST=$(echo \"$RESPONSE\" | jq -r '.data.manifest')\ncurl -fsS -X POST https://console-api.akash.network/v1/leases \\\n -H \"x-api-key: ${AKASH_API_KEY}\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"manifest\\\":$MANIFEST,\\\"leases\\\":[{\\\"dseq\\\":\\\"$DSEQ\\\",\\\"gseq\\\":1,\\\"oseq\\\":1,\\\"provider\\\":\\\"$PROVIDER\\\"}]}\"\n\necho \"Lease created. Polling for endpoint...\"\n```\n\nNote the explicit `set -euo pipefail` at the top. Without it, a failed `curl` in a pipeline would silently continue, and you would be none the wiser that your deployment never happened.\n\nFollowing the same API flow, we create the deployment, poll for bids, and wait.\n\n**The first attempt fails.** No bids arrive. After 30 retries, the deployment script exits and the pipeline errors out.\n\n## Step 3: Diagnosis and Fixing the SDL\n\nThe Coordinator Agent investigates. The SDL has two problems:\n\n### Problem 1: `signedBy` Constraints\n\nThe original SDL included a `signedBy` block with two specific provider addresses baked in. Only those two providers were authorised to bid. Neither was online or interested at the time of deployment. The result: zero bids.\n\nIncluding `signedBy` with a populated `anyOf` list restricts the deployment to an explicit allowlist of providers. If none of those providers participate, the deployment starves for bids indefinitely.\n\n**Fix:** Remove the `signedBy` block entirely. Omitting the constraint opens bidding to all active providers in the Akash marketplace.\n\n### Problem 2: Pricing Too Low\n\nThe original pricing was set to `1000 uakt`. At the time of deployment, the market had shifted and this price point was no longer competitive. Providers were ignoring the deployment in favour of higher paying workloads.\n\n**Fix:** Bump pricing to `10000 uakt`. On the next attempt, ten bids arrive within seconds. The cheapest provider offers `0.74 uakt/hr`.\n\nThese are not bugs you find in a compiler or a linter. They are market dynamics and configuration assumptions , exactly the kind of operational problem where a Review Worker's critique and a Coordinator's systems thinking shine.\n\n## Step 4: Creating the Lease and Finding the Endpoint\n\nWith bids available, the script selects the cheapest provider and creates a lease. The Console API responds with the lease status, including the ingress endpoint assigned by the provider:\n\n```json\n{\n \"data\": {\n \"leases\": [{\n \"status\": {\n \"services\": {\n \"web\": {\n \"uris\": [\n \"qhesrugdbhc2j1kko6g8fiv3go.ingress.provider.com\"\n ],\n \"ready_replicas\": 1\n }\n }\n }\n }]\n }\n}\n```\n\nThe Review Worker warned that providers need time to pull the image , especially from a private registry that requires authentication negotiation. We poll the deployment status every 5 seconds:\n\n```bash\n# Poll deployment status for ready replicas\necho \"Checking service readiness...\"\nfor i in $(seq 1 24); do\n STATUS=$(curl -fsS \"https://console-api.akash.network/v1/deployments/$DSEQ\" \\\n -H \"x-api-key: ${AKASH_API_KEY}\")\n READY=$(echo \"$STATUS\" | jq '.data.leases[0].status.services.web.ready_replicas')\n echo \"Attempt $i: ready_replicas=$READY\"\n if [ \"$READY\" != \"0\" ] && [ \"$READY\" != \"null\" ]; then\n echo \"Deployment ready!\"\n break\n fi\n sleep 5\ndone\n\n# Extract and health-check the endpoint\nURI=$(echo \"$STATUS\" | jq -r '.data.leases[0].status.services.web.uris[0]')\necho \"Endpoint: http://$URI\"\ncurl -fsS --max-time 10 \"http://$URI\"\n```\n\nAfter roughly 30 seconds the service reports `ready_replicas: 1` and a health check against the public endpoint returns HTTP 200. Your container is now live on Akash , deployed on decentralised infrastructure and exposed to the internet.\n\n## Step 5: The Private Registry Pattern\n\nThe complete flow looks like this:\n\n1. **CI builds the image** using Docker in Docker, tags with the Git commit SHA, and pushes to the private registry.\n2. **Deployment script substitutes** the SDL template variables at runtime:\n * `` → CI secret\n * `` → CI secret\n * `:latest` tag → the pinned SHA tag for reproducibility\n3. **Akash providers authenticate** to the registry using the injected credentials and pull the image.\n4. **Container starts** on the provider's infrastructure. The Akash ingress system exposes it on a public endpoint.\n\nThe SDL carries authentication details inline, but at no point are those credentials written to the Git repository. They enter the system only at deployment time, via CI/CD environment variables passed to the deployment script.\n\n## Step 6: Tear Down\n\nAkash deployments are charged continuously against the escrow deposit. When you want to stop paying, close the deployment:\n\n```bash\n# Close deployment — refunds remaining deposit\ncurl -X DELETE \"https://console-api.akash.network/v1/deployments/$DSEQ\" \\\n -H \"x-api-key: ${AKASH_API_KEY}\"\n```\n\nThe Console API returns the remaining escrow balance and the deployment transitions to `closed` state. If you forget this step, the provider continues billing your deposit until it is exhausted and the lease is closed automatically.\n\n## Key Decisions and Tradeoffs\n\n* **Pin tags with Git commit SHA** \n Rationale: reproducible deployments where the Akash SDL points to an exact image. \n Tradeoff: the SDL or deployment template must be updated for every release.\n\n* **Remove `signedBy` constraints** \n Rationale: allow all active providers to bid. \n Tradeoff: less direct control over the provider trust model.\n\n* **Use a competitive `uakt` price** \n Rationale: attract bids under current market conditions. \n Tradeoff: higher cost than the theoretical minimum.\n\n* **Pass registry credentials through the SDL at deployment time** \n Rationale: required for provider side private image pulls. \n Tradeoff: credentials can leak if logs are too verbose, so scripts should avoid shell tracing and verbose curl output.\n\n* **Use the managed wallet API with `x-api-key`** \n Rationale: avoids self custody key management inside CI. \n Tradeoff: depends on Akash Console API availability.\n\nThe Review Worker flagged each of these tradeoffs. The Coordinator Agent made the final calls. The Implementation Worker ensured the scripts executed correctly.\n\n## What This Pattern enables\n\nUsing a multi agent system for deployment does not just speed up the work. It changes the nature of the debugging process:\n\n* **Parallel investigation**: While the Implementation Worker was rewriting the CI pipeline to handle the Docker tag problem, the Review Worker was analysing SDL semantics and price dynamics.\n* **Persistent artifacts**: Every agent output is a file in a Git repo. The deployment script, the SDL manifest, and the CI configuration all have version history.\n* **Cross-domain critique**: The Review Worker spotted that a populated `signedBy` block with unavailable providers is a silent failure mode , not a syntax error, but a semantic one that blocks all bidding. A single developer might have stared at the YAML for hours before realising the market dynamics issue.\n* **Standardised workflow**: The `deploy akash` skill captures the complete workflow , prerequisites, API calls, error modes, and teardown , so future agents inherit proven deployment logic.\n\n## Closing\n\nAkash provides an alternative deployment model for teams interested in decentralised infrastructure, marketplace based compute allocation, and reduced dependence on traditional hyperscalers.\n\nDeploying to a decentralised compute marketplace is not just about writing the right YAML. It is about understanding marketplace dynamics, authentication flows, container image lifecycles, and operational monitoring , all at once.\n\nA multi agent system with specialised workers makes this tractable. The Implementation Worker handles the build pipeline. The Review Worker validates assumptions and catches silent failures. The Coordinator Agent integrates the pieces and manages the deployment lifecycle.\n\nUsing AkashML backed Hermes agents, the workflow can move from repository to deployment quickly while maintaining review and operational validation steps.","created_at",1779946154,"id","fdb19b87d9cbeae719d829ca266752202382cd8860faff94a924fb89e9e8b8e2","kind",30023,"pubkey","721be1b24ae584258e3d8e69d5afb6701ab8ef2622248cc91b13481d2cee7c6e","sig","bd720697853b87942379b40b94d800440ce38a2451bafe89a99b828097bee89c545c3b21712fc293847a1e74f37fa79c5875983d8301c2ee5f771b1f001baecb","tags",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],[60,61],[58,59],[56,57],[43,55],[43,54],[43,53],[43,52],[43,51],[49,50],[43,48],[43,12],[43,47],[43,46],[43,45],[43,44],"t","deployment","containers","ai-agents","hermes","akash","summary","A walkthrough of deploying a containerised application to the Akash Network using a Hermes multi-agent system powered by AkashML AI models. Covers the full lifecycle from Dockerfile to a live deployment on decentralised infrastructure.","blog","howto","grownostr","nip","nostr","published_at","1779946154","title","Deploying to Akash with a Multi-Agent Team and Private Container Registries","d","deploying-to-akash-with-a-multi-agent-team-and-private-container-registries"]