Talk →
Case · Akash Network Provider Console

The provider console, open and in production.

Open-source provider tooling for the Akash Network — onboarding, attribute management, and upgrade across Kubernetes, blockchain, and SSH-based remote provisioning. Built and maintained end-to-end by one team across the stack.

Engagement
SectorDecentralized cloud · DePIN
StatusOngoing
Started2022
TeamSenior engineers, end-to-end
TechFastAPI · Next.js · Kubernetes · Helm · Cosmos-SDK
§ 01
The situation

A network with no on-ramp for new providers.

Akash Network is a decentralized cloud computing marketplace — buyers post deployment requirements, providers bid to run them, the chain handles settlement. The user side of that marketplace had a working tool for tenants deploying containers. The provider side did not.

For most of the network's history, becoming a provider meant working through a CLI — a learning curve most non-Linux-native operators do not get past. The on-ramp for new providers was the gap, and the network's growth was capped by it.

The Akash core team and the broader community decided the right path forward was a purpose-built, open-source provider tool — one that could evolve under community ownership, cover the full provider lifecycle (onboarding, attribute management, upgrade, monitoring), and become the on-ramp for the next wave of providers. Arc10 was brought in to build it.

§ 02
The approach

Three surfaces, one team.

This is not the kind of project a small team picks up and figures out as they go. The provider lifecycle on Akash spans three deeply different surfaces:

01

Cosmos-SDK / Tendermint chain

Provider attributes, bids, leases, and settlement live on-chain. Anything the console does on a provider's behalf eventually translates into signed transactions against the Akash chain.

02

Kubernetes on the provider's hardware

Every Akash provider runs a real Kubernetes cluster. Provider setup means standing one up. Provider management means managing it. Provider upgrades mean upgrading workloads on it without breaking the leases already running.

03

SSH-based remote provisioning

Providers operate hardware the console does not own. The only way to set them up, check their health, and run upgrade actions is to reach into their machines from a managed control plane — handling keys, secrets, and audit cleanly enough that providers will trust it with root.

Most of the engineering work that matters on this project is the work that connects those three surfaces — translating a click in the GUI into a Helm chart applied on the provider's cluster, signed by the provider's on-chain key, with the result reflected back into the dashboard. The notebook version of any one surface is straightforward. The production version of all three, working together, is the project.

Arc10 owned the build end to end. Senior engineers across the FastAPI backend, the MongoDB data model, the SSH-based remote-execution layer, the Akash chain integration, the Helm orchestration, and the Next.js console frontend. A single team across the stack — the only model that produces a system this coherent.

§ 03
What we built

Six surfaces, in one team.

01

Provider onboarding flow

A multi-step GUI that takes a new provider from "I have a server" to "I am bidding on Akash leases." Behind the scenes, the flow runs SSH-based environment checks against the provider's machine, validates GPU and resource declarations against the canonical Akash data, generates and registers on-chain provider keys, deploys the provider's Kubernetes operator and provider services via Helm, and writes the provider's attributes onto the chain. A single guided flow for what was previously a multi-day CLI exercise.

02

FastAPI backend with SSH-based remote execution

The API is a FastAPI service backed by MongoDB. The non-obvious work is the remote-execution layer: a hardened SSH path that lets the API run privileged operations on a provider's machine using a base64-encoded private key, with the key never leaving the controlled environment. Every step of the onboarding and management flow goes through that layer — environment checks, package installation, Helm operations, log retrieval, upgrade actions.

03

Akash chain integration

The console orchestrates against a specific Akash chain ID, with version awareness on both the chain and the provider services. Provider attribute updates, status changes, and on-chain operations are signed and submitted through configurable keyring backends. The system tracks its own version awareness against the chain's — Akash, like any healthy chain, ships breaking changes the tooling has to absorb.

04

Pricing engine integration

Providers price their bids against a reference pricing script that is itself versioned and externally hosted. The console pulls the current pricing logic at runtime, applies it to the provider's declared resources, and produces the bid pricing the provider then signs and publishes. Decoupling the pricing logic from the console binary lets the network update pricing models without forcing every provider to update the console first.

05

Provider management surface

Beyond onboarding, the console handles the full operational lifecycle: attribute updates, provider upgrades (orchestrated rolling updates of the provider services Helm chart on the provider's own Kubernetes cluster), GPU model registration against the canonical Akash GPU data, and dashboards showing leases, earnings, and resource utilization. All open-source under Apache 2.0.

06

Next.js / TypeScript console

The provider-facing console is a Next.js application written in TypeScript, packaged and deployed via Docker. The frontend talks only to the FastAPI backend; it never holds Akash keys or provider SSH credentials directly. That separation is enforced at the architecture level, not just by convention.

§ 04
Outcomes

Live, open, and adopted.

Production figures
Adoption50%+
Of community providers running on the Console
StatusLive
In production · primary provider tooling on the network
LicenseApache 2.0
Open source · public release history and contribution surface
  • Replaces the closed-source predecessor that previously served the majority of providers — the open ecosystem now runs on tooling it owns.
  • Provider lifecycle covered end-to-end — onboarding, management, upgrade, monitoring — in one tool, where the network previously had a fragmented mix of CLI workflows, third-party GUIs, and tribal knowledge.
  • Architecture chosen to absorb change: chain-version awareness, externally hosted pricing logic, service-isolated frontend that never holds keys directly.
Engagement footnote

Started in 2022. Still shipping. The same team that built it is the team that maintains it.

Back to the work
StatusOngoing
Started2022
WorkstreamArc10-owned, end-to-end
TeamSenior engineers across FastAPI, MongoDB, SSH remote-execution, Akash chain, Helm, Next.js
Talk

Talk to a senior engineer.

Want to walk through the SSH-based provisioning model, the Helm orchestration design, or the chain-version handling? The senior engineers who built it will take the call.

What to expect
Emailhello@arc10.io
First replyWithin one business day
First call30 minutes with a senior engineer
No salesEngineering questions, engineering answers