Dashboard Redesigned

We are unveiling the next evolution of the Spheron Dashboard. If you’re a long-time Spheron user. Visit the dashboard, it will be very obvious that there have been changes. The UI is completely redesigned and much more beautiful now. There are also UX tweaks everywhere, based on feedback from users.

With the new design, we have focused on making different components more accessible to the user and intuitive to play around with. Some of the new features added are as follows:

Introducing new Git Providers - Gitlab & Bitbucket

We have completed our integration with Gitlab & Bitbucket for both login and importing projects. Now users can easily log in and signup to the Spheron dashboard using Gitlab and Bitbucket too. As of now, signup with any provider will create a new profile in Spheron. We are working on making it possible for connecting all 3 providers with a single profile on the platform. We will be releasing this in our subsequent releases. Apart from this, we have also integrated Gitlab & Bitbucket for importing your projects. You can import all repositories from Github, Gitlab & Bitbucket. Search and Refresh options are also added to the UI for easy searching of repositories and refreshing the repositories list.

When choosing a repository, more information is provided like **Framework, Updated At, Links, etc. Along with it, we have Pagination in place to improve the performance of fetching all the repositories.

Better Git Workflow

We have worked on making it possible to collaborate and see previews directly in the Github repository. We have added lots of meaningful workflows to make it easy for a team to collaborate effectively without visiting the dashboard. Some of these new feature addition includes:

PR Comments

The new system post comments whenever users create a PR and start deploying the last commit of the PR. After successful deployment, it will post the deployment preview link and log link.

PR Checks

The new system also posts the deployment checks as the deployment gets started for any commit. It can also be seen in the PR which will redirect to the deployment log page.

Github Environments

The new system also creates a deployment environment in Github. By default, users get 2 deployment environments from the platform - **Production & Development. More details in section Deployment Environment in our docs. We post the deployment link to these deployment environments on Github such that the team can view deployment history.

Gitlab Builds

This is the same as the Github Environments, just with a different flavor of Gitlab. Similar to Github Env, we create 2 build pipelines based on the 2 deployment environments. We add deployment links to these builds for the team to view all the deployment history done for a specific environment in Gitlab. With the addition of new workflow for Git Provider, the continuous deployment is now enabled by default. For more details, check out our Git Provider Workflows section in our doc.

Deployment Environment

As mentioned in the Git Workflow, we have introduced a new feature with this new release. A deployment environment is a way to manage the continuous deployment for specific branches and deployment protocols. By default, we provide 2 deployment environments

• Production & Development. You can add more environments, but be aware that, adding a new environment requires you to pay a bonus for it. Users can deactivate an environment, this will stop all the future continuous deployment of the branches that are connected with this environment. For more details, check out our Deployment Environment section in the our docs.

Deployment Experience Enhancement

We have improved a lot of features and UX of deployment based on the feedback we got from our community. Some of these new updates are:

Concurrent Builds

We have implemented a concurrent build in this release. Every organization gets 1 concurrent build by default. An organization can increase the concurrent build limit by buying bonuses for concurrent builds. When there is more than 1 deployment in the organization, the deployment gets into a Queue state and waits for the previous deployment to get accomplished. Once the previous deployment is done, the platform triggers the queued deployment to running state.

Deployment Authorization

We have implemented an authorization mechanism for deployments. With this, the owner or admin can authorize a particular deployment. A deployment requires authorization when the member trying to deploy a commit from GitHub is not a part of the organization in Spheron. Another instance of authorization is when an external Pull Request is made to the project.

Deployment Creator

We have also implemented mapping of deployment with the user to maintain which member is triggering the deployments. This also takes care of commit-based deployment as we map the committed owner with the users in the organization.

Log Enhancement

We have improved build & deployment logs and added colors & background to make it more intuitive to view warnings and errors during the deployment. For more details, check out our Deployments section in the our docs.

Role & Permissions

With the new release, we have implemented Roles for organization members to give finer Permission to the dashboard and other features in the platform. We have created 3 Roles: - Owner - The creator of the organization will be given the owner role by default. An owner can make other members: the owner, or the admin of the organization. The owner has the highest permission in the organization.

• Admin: The admin has the second-highest permissions in the organization. Admin has permission to update billing details including upgrading and attaching wallet for payments.
• Member: The member can only deploy projects and view details around them. When a member joins an organization, he will automatically be given a Member role by default. The Admin or Owner can then change his role. For more details, check out our Roles & Permission section in the our docs.

Notifications

We now provide specific notifications to all the members & admin of the organization. This also includes promotional notifications that users might be interested in. Users can click on notifications to go to an external link. Currently, we have implemented Billing and Member Invitation related notifications. Also, we have implemented chrome notifications whenever a notification is sent to a user. This will allow notifications to be notified even without being on the app all the time. For more details, check out our User Notification section in the our docs.

Introduction Subscription & Bonus

We are introducing a completely redefined subscription model with web3.0 flavor in it. We have built an onchain subscription model, where users can attach their wallets and the subscription payment is charged every 30 days. Users can specify which Token & Network they want to pay a subscription on. We have implemented a smart contract that can charge users for subscription-based on the subscription parameters. All the subscription and bonus parameter prices are stored inside the contract which can only be updated by the governance wallet. The payment is triggered from the Spheron platform so that users don’t have to pay any gas fees for any onchain transactions. How is the smart contract transfer funds from the user's wallet? It’s simple! before we trigger payment from the smart contract, we ask users to give specific allowances to the smart contract and the smart contract can only transfer the specified approved amount. Even better for users is that the approval’s transaction is made gassless by integrating Biconomy. The subscription includes different components that make it easier for users to understand the process:

Wallet

Attaching your account need users to specify token, network, and wallet provider. Currently, we only provide 4 different types of tokens - USDT, WMATIC, DAI, and WETH that be used to pay the subscription. Users can also choose between multiple networks as well. We currently provide only 1 network - Polygon Mumbai (Testnet) to choose from, but in the future, we will be adding more chains. Also for wallet providers, users can only choose Metamask, but we will add more providers as well. Note: Only the Owners & Admins of the organization can attach the wallet and upgrade the plan.

Upgrade Plan

Upgrading a plan is very simple! Users just need to approve the token value and click on Pay. Spheron platform will start the subscription workflow as soon as the pay button is clicked. We cut the amount in advance and increase the limit immediately after the payment is successful. All the subscription & bonus parameter is stored inside our smart contract which takes the parameter and its amount to calculate the total subscription value in USD and convert it to token value based on the current market price using Chainlink’s oracle. But all these are abstracted from users, but they can view details in their invoice. Note: Parameter’s values are pegged with USD in the smart contract and can only be updated by the governance wallet.

Invoice

The invoice provides comprehensive details on the payment history. It provides you details like payment date & time, the token used for making this payment, token market value, and all the subscription & bonuses parameters and their unit prices. You can also view which network the payment has been made on.

Usage

The usage gives users an overview of the different types of limits. When the user crossed any limit, the organization will go under an Overdue state, which will stop all future deployments. To prevent it from happening, members can periodically check the usage and based on that buy bonuses (or addons) to increase the limit. Later, we will implement notifications to admins to control the usage or put an alarm if usage increases by a certain limit. For more details, check out our Subscription & Bonus section in the our docs.

NFT Gatepass

As we launch the Aqua Release, we have added gated access to the platform. We have implemented NFT gated access to the platform where only whitelisted users can mint their NFT and access the platform. This is to give special privileges to the initial adopters. Every time someone logs in, the platform check if the address attached to the users still contain at least 1 NFT and then give them access to the platform. So, if a user used the NFT to access the platform first and then transfer it to someone else, he won’t be able to access the dashboard again. We are also using the NFTs Subgraph to fetch all the NFTs the user holds and Moralis in the backend to check if the user holds at least 1 NFT. NFT will provide lots of privileges to the users who hold them in the future. Some of the privileges are mentioned on our Website, please visit to know more. For more details, check out our NFT Gatepass section in the our docs.