Flavio Espinoza

The Deployment Wizard — The front door. A five-step stepper -- Featured Apps, Select, Configure, Review, Deploy -- that turns “post a workload to a blockchain marketplace” into something a developer can follow without reading the protocol docs.

1. A.Built in React (create-react-app) with Material-UI, the wizard is a stepper-driven flow that carries form state across all five steps (Featured Apps → Select → Configure → Review → Deploy), so a user can move backward and forward without losing input instead of each step being a dead end.
2. B.Multi-step form validation with Formik gated progress at each step, so a user could not reach “Deploy” with an invalid SDL or a misconfigured resource request -- the errors surfaced where the mistake was made, not at the end.
3. C.A template-driven start: curated, pre-validated SDL configurations (18-plus blockchain node presets -- Validator, RPC, and Sentry nodes among them) pulled via the GitHub API, so the most common deployments started from a working manifest instead of a blank editor.

The SDL Editor — For anything beyond a template, the user works with SDL -- Akash's YAML dialect describing the container, resources, and pricing. A blank YAML box is a wall; a real editor with validation is a ramp.

1. A.SDL editing runs on Monaco (the engine behind VS Code) with monaco-yaml, wired into the wizard so a user could edit their manifest live during the five-step flow -- real syntax highlighting, inline validation, and autocomplete instead of a plain textarea.
2. B.The editor surfaced schema validation as the user typed, with the failure pointing at the offending line -- the same “fail where the mistake is” principle as the wizard, applied to free-form config.
3. C.A visual SDL builder sat alongside the raw editor for users who did not want to touch YAML at all, both views driving the same underlying manifest -- part of the editing surface wired into the deployment flow, shipped in the first MVP and the first commercial release.

The Preflight Gate -- Wallet and Certificate — Before any deploy, the console verifies the prerequisites the network requires: a connected wallet, a minimum balance (at least 5 AKT), and a valid certificate. Making those explicit and actionable in one place -- so a developer is never guessing why a deploy will not go out -- was a core part of the console's job.

1. A.Integrated Keplr (the Cosmos browser wallet) for blockchain auth and transaction signing, using offline signers with amino-json serialization and auto-adjusted gas estimation across the full deployment lifecycle -- create, update, lease, and close. Akash runs on Cosmos, so every signature here is a Cosmos-SDK transaction.
2. B.Built the certificate flow end to end: generate an X.509 keypair in the browser, encrypt the private key with AES-256 and keep it in local storage so no secret ever touched a server, and register the public cert on-chain via MsgCreateCertificate so providers could validate the client against the ledger. The “Create Certificate” button in the exhibits is that whole pipeline behind one click.
3. C.Surfaced the minimum-balance requirement (at least 5 AKT) in the gate itself, so a newcomer who had not yet funded a wallet saw exactly what was missing instead of hitting a failed deploy.

The Provider Marketplace — Once the deployment is posted on-chain, independent providers bid to run it. The marketplace UI is where a user turns a wall of blockchain bids into one informed click.

1. A.Rendered live bids from across the provider network, each card showing a monthly cost estimate, the provider's on-chain address, and an audit badge, refreshable in place as new bids arrived.
2. B.An “Only Audited” filter let users restrict to vetted providers in one toggle -- a trust shortcut on a marketplace of anonymous datacenters.
3. C.Selecting a bid constructed and signed a MsgCreateLease transaction, and the chosen provider then received the manifest over the proxy -- the moment the deployment stops being an order and becomes a running workload.

Real-Time Monitoring — Closing the loop. After a lease is live, the user needs to see their app actually running -- logs, events, lease status -- streamed back from a provider's Kubernetes cluster they do not control. This is where the mTLS proxy earns its keep.

1. A.Designed a Fastify mutual-TLS proxy gateway that bridged the browser to distributed provider infrastructure: it injected the client certificate into each provider connection and relayed WebSocket streams, so the browser got live data without ever holding the provider's TLS trust directly.
2. B.Streamed application logs and Kubernetes events in real time over those WebSocket connections, with throttled rendering and stick-to-bottom autoscroll so a chatty container did not lock up the tab -- continuous-stream UI tuned for the failure mode where data never stops.
3. C.Surfaced lease accounting alongside the logs -- cost per month, spent, balance, time remaining -- and an interactive shell (xterm) into the running container, so monitoring, billing, and debugging lived on one screen across 100-plus independent providers.

State and Delivery Architecture — The layer under all of it -- how the app held state, and how it got to production.

1. A.Atomic state using parameterized atomFamily patterns (Jotai) for per-deployment isolation, so each deployment's state was independent and a change to one lease did not re-render the others -- a deliberate structure that kept the UI fast. (We moved from Recoil to Jotai early when Recoil proved incompatible with the latest React; that story is in the introduction.)
2. B.Server state via React Query for the chain and provider reads -- bids, lease status, balances -- so the polling, caching, and refetch logic lived in one disciplined place instead of scattered across components.
3. C.A three-tier monorepo (web / Fastify proxy / API) on Yarn workspaces with unified versioning via custom Node scripts, shipped through a four-stage GitHub Actions pipeline: auto-versioning, multi-arch Docker builds to GHCR, staging deploy, and approval-gated production. The console also dogfooded its own product -- deployed onto Akash itself via templated SDL, the platform running on the marketplace it managed.

What this project shows — The whole console is an onboarding machine. Its job was to take the single hardest developer onboarding I have seen -- a nine-step blockchain protocol, full of wallets and signatures and on-chain certificates -- and make it finishable. That is the work: not a feature, a protocol made walkable. I owned the front end that did it: the React application and the Node mTLS proxy behind it that fed the Akash network, integrating my teammates' work and shipping it on the pipeline I built. Developers shipped real workloads through it.