Polkadot Deployment Portal: The 1 Click Solution For Polkadot

Ecosystem
1

Polkadot Deployment Portal: The 1 Click Solution For Polkadot

Want to be an early tester of the Polkadot Deployment Portal?
[https://docs.google.com/forms/d/1th3GKJCSjzrmqwzDs62yA1hGUZnQUCPqmaUYLwSiHo4/viewform?edit_requested=true ]

Summary

Over the course of the last 6 months, the Parity team has been diligently working on building a 1 - Click Deployment solution for Polkadot. The Polkadot Deployment Portal (PDP), launching soon, will revolutionise how you deploy on Polkadot. Anyone will be able to take advantage of the PDP’s intuitive UI and capabilities, allowing you to configure, deploy and manage a rollup with a few simple clicks. This post aims to break down what it is, why we need it & when it will launch.

Polkadot is facing a problem

Polkadot is facing a critical issue, especially when it comes to the developer experience. Whilst the tech is incredible, for some it can be somewhat inaccessible. So what is it all for if actually deploying to Polkadot is deemed ‘too complex’?

Great DevEx is a priority, and ensuring a clear path for developers, making the choice of deploying as simple and as easy as possible is how we achieve it. If we choose to ignore DevEx, and ignore making the deployment paths simpler and more accessible, the products, features and tech we proudly build will never get the true recognition they deserve. Bringing the cost of experimentation down is also how we improve the developer experience.

So what’s the solution?

Today we’re proudly presenting the Polkadot Deployment Portal. A 1 Click deployment solution for Polkadot rollups with the goal to make building on Polkadot easier and more accessible. As it stands, building on Polkadot is perceived as very complicated and slow. If we want to attract new builders, tinkerers and founders to our ecosystem we should make the path forward for them as easy as possible: this not only encourages experimentation but also lowers the barriers to adoption. If anyone can build on Polkadot, we’ve achieved a true pillar of the Web3 ethos, “permissionlessness for the masses”

The PDP ensures the complexity associated with deploying is addressed, meaning builders should only have to think about their business logic, and the infrastructure part, including coretime, is taken care of for them.

Deploy in a matter of seconds, not days

The PDP’s UI allows you to configure your rollup with ease, allowing you to choose your runtime template, chain to deploy and when you’d like to schedule your deployment.

1375×1600 166 KB

New Rollup form

The PDP offers 3 main configuration areas, giving you full control over your Polkadot Native Rollup, customizing it to meet your specific needs.

General Configuration - Allows you to customise general settings, such as Token name, ticker, decimals / supply and your SUDO address.

Environment Selection - Allows you to choose the runtime that suits your needs as well as the target for your deployment, such as Polkadot or Kusama (for live networks) Paseo or Westend (for testing stuff out).

PDP gives you the ability to choose between OZ Generic Runtime or the OZ EVM Runtime templates, both of which offer unique benefits and qualities. The list of templates will be extended further, offering you maximum flexibility and fast time to market.Once selected, you can deploy to production on either Polkadot & Kusama, or deploy to testnet on Westend & Paseo.

Coretime – Allows you to choose the Agile Coretime option, providing you with 3 options which we have listed below.

  • I don’t need a core

    • By selecting this option, you indicate that you do not wish to purchase or assign Agile Coretime at this moment and have no immediate need for Coretime. However, you will still have the option to purchase and assign Coretime later, once you are ready for your rollup to produce blocks.

  • Interlaced core

    • Choosing this option will assign a preordered ⅛ of a core. This is suitable for POCs, MVPs, or other projects that do not require fast finality. A ⅛ of a core will produce a block every 48 seconds. One of the advantages of this option is that it is more cost-effective compared to the “Full core” option.

  • Full core

    • Selecting this option means that a full core will be assigned to your project, ensuring that your project becomes the sole owner of the core. The Full core will produce a block every 6 seconds and Relay chain tasks will be executed on each block.

Once you’ve selected your configuration, the PDP will summarise what you get, whilst also displaying how much your deployment will cost.

874×1076 43.2 KB

Sign and Deploy form

You’re now ready to deploy! Simply click the ‘sign & deploy’ button and you’re on your way to building on Polkadot, easy right?

How does it work?

The diagram below shows a high level architecture of the Polkadot Deployment Portal, explaining how each module and bit of the PDP interacts with each other.

1600×1281 171 KB

High level architecture of the PDP

Through the UI, users of the PDP will be able to configure the chainspecs of the new rollup and deploy 1 collator and RPC. Providing Coretime is available, as soon as the rollup is configured and passes the onboarding after registration, block production will commence. It’s important to note, that the configuration of the collator and RPC may take from 10 minutes to 2 hours.

The diagram above showcases 2 important components which make up the PDP.

  • The PDP Portal (UI)
  • Resources Orchestration (Backend)

The PDP Portal (UI)

The Portal is where the user interacts with everything relating to the PDP. A user will interact, deploy, manage and monitor their rollups through the UI. Overall, a user can do the following through the PDP’s UI

  • Invite and welcome others into their team
  • Generate API keys which will interact with POP CLI
  • Access the PDP’s docs
  • Manage their deployed rollups
  • Create a new rollup

The create a new rollup service will communicate with the backend of the PDP via REST, which in turn serves as the authoritative source for all deployed rollups across the project.

Resources Orchestration (Backend)

The backend of the PDP is the engine behind the wonder, it’s responsible for managing the infrastructure, including the creation and maintenance of resources. At the current moment, the application is deployed via Parity infrastructure (argocd & kubernetes)

As the process of provisioning and configuring the rollup is quite long, we use a queue management tool, otherwise known as pg-boss, to handle a range of tasks such as provisioning, destroying and recurring jobs (cron) for long running work.

Below we’ve highlighted the provisioning pipeline

  • Template & Chainspec Builder - Takes the binary of a selected template and generates the rollup chainspecs file. This will also create the collator keys which in turn will be injected later during the configuration. Templates are pre-built and released into GitHub - paritytech/pdp-templates: Pre-Building node and runtimes of different parachain templates

  • To make the deployment of resources as seamless as possible, Pulumi is utilised, self-hosted with the state stored on S3, preventing the orphaning of cloud resources such as VMs, volumes, DNS) on Scaleway.

  • Ansible configures the collator and RPC services on provisioned VMs using paritytech/ansible-polkadot roles (nginx/node) developed by the Parity DevOps team.

  • Deployment durations can however range quite significantly, ranging from 10 minutes to 2 hours depending on the network and the resource availability. As we progress, we plan to optimize this further.

There are also some recurring (cron) jobs that do the following

  • Create pure-proxies for users in advance, which will then reduce the number of signatures on the first deployment. If a user were to deploy using a multi-sig, this would act as a significant UX barrier reduction.

  • Buy & Interlace Coretime per each chain we support, a crucial part of the PDP, which allows us to offer ready-to-use Coretime within the current cycle, if your rollup is needing to produce blocks immediately after deployment.

An MVP that showcases this structure is already working, and can be found at deploypolkadot.xyz. Access is currently limited but if you want to play around, ping me/us/ something and we’ll give you a walkthrough.

So, what’s next?

Development of the PDP is ongoing, with the bulk of the effort aimed at bringing PDP to production sooner than you would think. Our goal is to have 3-5 testers on Kusama, live in production, by mid April 2025.

Feature Freeze

The team is currently working towards a feature freeze by the end of March, ensuring that we’re ready to deploy on Kusama as soon as possible. A user will be able to deploy a rollup on Kusama in seconds.

Progress is coming along, we’ve actually already tested a successful Kusama deployment in the past

Call For Testers

As mentioned at the start opening up applications for 3-5 testers on Kusama to deploy a rollup and provide feedback.

If you’re interested, fill out the form here.

Got questions? Reach out!

If you’re interested in becoming a beta tester, we’ve opened up a TG Group dedicated to supporting testers and collecting feedback.

Join the group here.

Alternatively, if you’d like to speak to us 1 - 1, then please dont hesitate to get in touch.

Email: remy@parity.io
Telegram: @Remy_LeBerre

A thank you to the team,

This post was a collaborative effort from the Parity PDP & Product Strategy teams, huge kudos to all who contributed their time between development to help write this article.

Special thanks to @mordamax, @Cyr06130, @mcornholio, @Karim, @ShawnCoe, @davidcastro , @piggydoughnut @pavel.baluev and of course, the man behind the magic who led this project from the start, spearheaded development and brought the project to where it is today - @santi

35 Likes
2

I see you mention the templates, but can they be edited? Can I add a pallet that I’ve built? I see no mention of this beyond the intro “builders should only have to think about their business logic, and the infrastructure part, including coretime, is taken care of for them.”

Without being able to customize the runtime this seems fairly useless beyond possibly helping new developers get familiar with the process of launching a parachain in general. I’m assuming that you CAN customize it, but I don’t see it mentioned here.

4 Likes
3

Nice. ​This feature has been highly anticipated.

However, will the PDP also support one-click deployment for validators, collators, and RPC nodes (think i.e. Outline VPN UI)? Simplifying these setups would significantly enhance the network’s accessibility and encourage broader participation.

4

GM @YungBeef - Technically yes, you can clone that particular template, edit this, then perform runtime upgrades on an already running Rollup, then it’ll be possible.

There should definitely be options to either start blank and upgrade or provide your own code, which should cover most avenues.

Good feedback though, thanks! Perhaps we can cover this topic is deeper detail in the next edition.

1 Like
5

Individually, I suggest that Polkadot should apply for a portion of funds from the national treasury to acquire domain names that are highly relevant to the Polkadot brand projects. I am confident that the PDP team has invested considerable effort in developing this feature, which is also highly demanded by the market, as it has indeed facilitated the deployment of Polkadot. However, I believe that using a domain name like deploypolkadot.xyz is somewhat stingy and will significantly diminish the effectiveness of promoting this application. A domain name is the first impression of a new project; Polkadot needs to pay attention to this brand impact.

In my memory, there was also a sales website for coretime, which was a significant innovation and improvement for Polkadot when it was launched. However, the domain name used was extremely ordinary, to the point that I still don’t know what the domain name is, or where I can find the real-time sales information for coretime.