# Cloudmos **Cloudmos** is an app that let's you deploy any [docker container](https://www.docker.com/) on the [Akash Network](https://akash.network) in a few clicks... 🛠   [](https://twitter.com/cloudmosio) [](https://discord.gg/akash)

• Quick Start
• Services
• Monitoring
• Example SQL Queries
• Running the Application
• How to run
• Database Structure

Quick start

We use docker with docker compose to run the services. This is the easiest way to get started. For instance to run the deploy-web service:

git clone git@github.com:akash-network/cloudmos.git ./console
cd console
npm run dc:up:dev -- deploy-web 

This would start the deploy-web service in development mode with all the dependencies (api, indexer, postgres) needed. While spinning up postgres it would also import a backup of the sandbox (by default) database to speed up the process.

For more details on how to run the other services or modes see the Running the Application section.

Services

Dataflow between services

Every services are nodejs applications written in typescript. They are deployed using docker. Both databases are PostgreSQL deployed on GCP.

Deploy Website

Website to deploy on Akash. It is using the Next.js framework. The data shown in the website comes from a combination of our API and akash nodes (REST).

Url: deploy.cloudmos.io
Directory: deploy-web

Provider Proxy

Used in the deploy website to proxy requests to providers. Needed since it's not possible to use the cert authentication system from the browser.

This is the equivalent of the Proxy used by the akash console.

Directory: provider-proxy

API

Provides data to the deploy website. The data is fetched from our Indexer database + coingecko for market data. This api also provide the endpoint for the Web3 Index integration.

Url: api.cloudmos.io
Directory: api

Indexer

Fetch the latest blocks from RPC nodes. Saves the blocks & stats to our Indexer Database. For details on how the indexer work see the Indexer README

Directory: indexer

Landing Page

Small landing page with a button to "Launch App".

Url: cloudmos.io
Directory: landing

Config

Directory containing public config file that are fetch by the deploy tool. This is to allow modifying some configurations on the spot without the need to redeploy the web interface.

Directory: config

Monitoring

• Sentry.io is integrated into all our services and allows us to catch js exceptions in the frontend as well as backend.
• HealthChecks.io is used to monitor the execution of our Scheduled Tasks. If a task is failing we get an email + alert in discord.
• Cronitor is used to monitor uptime. If our website or apis goes offline we get an email + alert in discord.
• Grafana dashboards allows us to see usage stats and syncing status. We can monitor block syncing and scheduled task there.
• Status Endpoints
  All our backend services have /status endpoints built into them allowing us to monitor health and view usage stats. Those endpoints are used by the other monitoring tools.

Example SQL Queries

See Example_Queries.md

Running the Application

This document provides instructions on how to set up and run the application, including steps for manual database restoration and using Docker Compose for ease of setup.

Using Docker and Docker Compose

This project's service are deployed using Docker and Docker Compose. The following sections provide instructions for setting up and running the application using Docker Compose. All the Dockerfiles are using multi-stage builds to optimize the image build processes. Same files are used to build both development and production images. There are 3 docker-compose files:

• docker-compose.build.yml: Base file solely building production images for the services. It can be used to verify the same build process as in CICD.
• docker-compose.prod.yml: This file is used to run the services in production mode. It also includes the database service which would fetch a remote backup and import it on init.
• docker-compose.yml: The default file to run all the services in development mode with features like hot-reload.

Some commands are added to package.json for convenience.

npm run dc:build # Build the production images
npm run dc:up:prod # Run the services in production mode
npm run dc:up:dev # Run the services in development mode
npm run dc:down # Stop the services referencing any possible service

Note: you may pass any docker compose related arguments to the above commands. E.g. to only start deploy-web service in development mode:

npm run dc:up:dev -- deploy-web

This would also properly spin up all the dependencies like the api.

Using Turbo Repo

Another way to run apps in dev mode is using turbo repo setup. Some available commands are:

npm run console:dev # run console ui in dev mode with dependencies
npm run stats:dev # run stats ui in dev mode with dependencies
npm run api:dev # run api in dev mode with dependencies
npm run indexer:dev # run indexer in dev mode with dependencies

Note the above commands still depend on docker to run postgres database. If you need to run them without db you can use the following commands:

npm run console:dev:no-db # run console ui in dev mode with dependencies but without postgres in docker
npm run stats:dev:no-db # run stats ui in dev mode with dependencies but without postgres in docker

Manual Database Restoration

Due to the extensive time required to index Akash from block #1, it's recommended to initialize your database using an existing backup for efficiency. This approach is particularly beneficial for development purposes.

Available Backups

• Mainnet Database (~30 GB): cloudmos-akash-mainnet.sql.gz
  • Suitable for scenarios requiring complete data.
• Sandbox Database (< 300 MB): cloudmos-akash-sandbox.sql.gz
  • Ideal for most development needs, although it may lack recent chain updates.

Restoration Steps

1. Create a PostgreSQL database.
2. Restore the database using psql. Ensure PostgreSQL tools are installed on your system.

For a .sql.gz file:

gunzip -c /path/to/cloudmos-akash-sandbox.sql.gz | psql --host "localhost" --port "5432" --username "postgres" --dbname "cloudmos-akash"

After restoring the database, you can proceed with the specific project's README instructions for further setup and running the application.

Database Structure

The database schemas is defined using sequelize-typescript in /shared/dbSchemas/. Models are separated into the following folders:

• base - Tables which are cosmos generic and are used for every chains
• akash - Tables which are akash specific (they are not created when initializing a database for another chain)
• user - Tables which are user specific. Contains tables for user settings and templates

Block

Transaction

Message

AddressReference

Keeps track of which addresses are involved in which txs (even if they are not the signer).

Day

Created for each days (UTC based), simplifies querying for daily stats.

Validator

Deployment

DeploymentGroup

DeploymentGroupResource

Lease

Bid

Provider

ProviderAttribute

ProviderAttributeSignature

Store audited attributes based on MsgSignProviderAttributes & MsgDeleteProviderAttributes.

ProviderSnapshot

Similar to stats on the Provider, but a new row is inserted for every uptime checks. This allows to graph the changes in resources over time as well as calculate an uptime percentage over a period.

ProviderSnapshotNodes

Keep track of ressources of individual provider nodes obtained through feature discovery.

ProviderSnapshotNodeCPU

Store CPU informations for each Provider Nodes

ProviderSnapshotNodeGPU

Store GPU informations for each Provider Nodes

Template

TemplateFavorite

Created when a user "favorite" a template

UserSetting