TenantsDeveloper Experience

Deployment GUI 

Feature A web based, low friction interface for deploying workloads on Akash.

Motivation For Akash to expand beyond its current user base of deeply technical developers familar with Kubernetes, YAML & SDL, it needs to provide a way for less technical users to get started & quickly find value.


Provider Services Refactor 

Feature Splitting Akash's backend provider service into microservices

Motivation Increase operational agility, and scalability by separating Akash blockchain and provider services. Reduce support burden by making it easier to troubleshoot

PartnersDeveloper Experience

Testnet Sandbox 

Feature A mirror of mainnet that lets users test without AKT.

Motivation Running testnets today requires us to coordinate distributing AKT to partners which slows things down. This would enable us to move partner integrations forward faster.

Developer Experience

Improved CLI 

Feature Updated Command-Line-Interface (CLI) that streamlines tenant deployment.

Motivation Reduce time to deploy for power users by offering a more streamlined approach to deploying a workload on Akash.


GPU Marketplace 

Feature Ability to source GPUs on the Akash marketplace and deploy workloads on them

Motivation Supporting GPUs on the Akash marketplace will open up new markets based on use cases such as Machine Learning, Artificial Intelligence, Proof-of-Work (PoW) and High Performance Computing (HPC) applications.

Developer Experience

UI Component Library 

Feature The UI component library is an open-source repo of code components, such as cards and buttons, that empowers the Akashian community to efficiently produce on-brand websites and applications.

Motivation The UI component library allows Akash to scale massively, empowering community members to directly build tools, rather than using the bandwidth and resources of one individual company. Because engineers aren’t always designers, their Akash initiatives have inconsistent branding and UI experiences, leading to confusion and mistrust from users.

Developer Experience

SDL Modules 

Feature Allow reusing of configuration files (SDL) thereby improving code use and enabling code sharing.

Motivation Being able to leverage previously built config files in a modular fashion improves developer productivity and also aligns with a fundamental DRY (Don't Repeat Yourself) principle of software engineering.


Network Usage Dashboard 

Feature A publicly accessible dashboard that displays usage statistics and availability capacity for the network with historical lookback.

Motivation The best way to get new users to trust Akash is to show proof that others have trusted it.

Log Retention 

Feature Retain logs through container restarts, likely using a 3rd party log retention service.

Motivation Retaining logs through container restarts is crucial to analyzing failures and improving reliability of applications that run on Akash.


Conditional Validation of Attributes 

Feature Allow tenants to decide which attributes they would like validated by an auditor.

Motivation Not all tenants care about every provider attribute equally. Offering tenants the ability to filter on specific attributes when looking for provider validation increases the number of providers they get, thereby driving adoption.

Provider Management Dashboard (PMD) 

Feature A dashboard that lets providers view the health of their clusters, manage pricing & supply, view usage.

Motivation Providers need better visibility to ensure they provide quality service to tenants.

Private Container Registry Support 

Feature Allow tenant deployments to use container images hosted in private container registries.

Motivation Drives adoption by allowing tenants that do not wish to make their container images public to also deploy on Akash.


Developer ExperienceTenantsProvidersMarkets

IP Leases 

Feature Allow tenants to request public IP addresses for services deployed on Akash.

Motivation A fixed IP address is essential before several new types of workloads and applications can run on Akash infrastrcture.

A fixed public IP also allows services to use known & desired ports, including those from the standard range (like VPN for example).


Persistent Storage 

Feature Offer tenants the option to persist data for their workloads, even when the workload restarts

Motivation Not being able to save data and state between restarts limited the range of applications and workloads that can be deployed on Akash. Allowing persistence of stored data helps drive wider adoption of the Akash cloud.

Read documentation here

Developer Experience

TTY (Shell) Access 

Feature Allow access to the shell of a container to run arbitrary commands (supported by the liux version of the shell).

Motivation Debugging application issues is difficult without the ability to run commands on the container shell.

Read documentation here

Developer Experience

Akash Javascript SDK 

Feature Offer libraries and ready to use examples of common functions for developers building applications usin the Akash API.

Motivation Like any public APIs, utilizing the Akash API requires developers to write wrappers for common function calls and logic. Offering standard functions like credential management, retries, data marshaling, serialization/ deserialization and more as libraries and examples, reduces dev time and bugs, thereby increasing developer adoption of the Akash API.

Read documentation here


Fractional uAKT 

Feature Allow tenants to spend a fraction of 1 AKT on a deployment.

Motivation Fractional uAKT removes the minimum cost of deployment. This makes light workloads like a crypto wallet or a personal blog more cost-efficient and consistent with resource consumption.

Read documentation here

Developer ExperienceTenants

Authorized Spend 

Feature Allow users to authorize another wallet to spend a preset amount of AKT from their wallet when deploying on Akash.

Motivation Authorized spend enables teams of developers to work together without having to share wallets.

Read full documentation here

CoreDeveloper Experience

Hostname Migration 

Feature Allow tenants to migrate the custom hostnames for their services from one deployment to another

Motivation Without hostname migration the only way for tenants to migrate requests for a service to a new deployment is by tearing down the old deployment and replacing it with the new one.

Deployment migration is necessary to ensure continuous operation through new application version deployments, rollbacks, scaling/ updown, repricing as well as canary deployments and other DevOps practices.

Read full documentation here