#12176 Polkadot Deployment Portal: The 1 Click Solution For Polkadot
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.
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.
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.
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: [email protected]
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
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.
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.
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.
This service would be very relevant to host on polkadot.cloud - we have a full time designer in @flez now exploring designs and flows - it would be great to discuss this with Parity and collaborate to bring this service to a first class domain and align marketing efforts. Is there a preferred channel to discuss @Remy_Parity ?
Polkadot Deployment Portal: April Update
Summary
As promised, we’ll be providing monthly updates to keep the community up to date on the latest regarding the Polkadot Deployment Portal. If you’ve not read the previous edition, which goes into detail about how the PDP works and the problems it solves, then check it out here.
Recap
In the previous update, we dove deeper into the problem that Polkadot was facing, specifically looking at the inaccessibility and complexity of deploying to Polkadot. We outlined why DevX is a priority and should continue to be a path to explore and how a better DevX and deployment solutions will allow our tech to truly get the recognition it deserves.
We proposed a solution, a way to allow anyone to deploy a rollup within a simple click and showcased the progress of the PDP team throughout the last 6 months, diving deep into the portal [UI] and the Backend [Resource orchestration] and explaining the capabilities of the service.
The team also sent out a PSA, calling all those willing to become part of the PDP beta testing programme, where we’re granting a small selection of the external ecosystem the opportunity to test the PDP, provide feedback and deploy using the services provided by the tool.
So, what’s the latest?
PDP x POP CLI Integration
The PDP and POP-CLI teams recently announced their recent collaboration, allowing the PDP to utilize POP-CLI’s local rollup-building capabilities. Builders can now,
- Leverage pre-built templates already in Pop CLI through the PDP
- Deploy directly from the CLI and switch over to the PDP UI for simple and easy infra management
- Spin up rollup infrastructure instantly, with no complex setup required
ParaRegistration Proxy implementation
The PDP team proposed, created and implemented a new proxy type called ‘ParaRegistration’ Proxy which allows the PDP to really abstract the complexity away from the builders. The new proxy type allows for,
- Reserving a ParaID
- Registering a Parachain
- Removing a proxy
The new flow of the proxy goes as follows;
Beta testing begins
With development progressing smoothly, the PDP team is preparing to onboard the first cohort of external builders to be the first to trial and test the portal.
Our engineers are doing the final checks ahead of onboarding, where we’re already seeing live block production in Westend.
The number of builders who wanted to test the PDP has exceeded our expectations, with many of you keen and eager to get involved and contribute. If you’ve previously signed up to be a beta tester, then there’s no need to register again.
Final Call!
The final call for beta testers is here, if you’ve not previously signed up and want to be the first to deploy a rollup using the new PDP portal, then sign up here.
UX & User Journey improvements
Both UX & DevX will always be a priority for the PDP, ensuring simplicity and abstracting needless mental workload from builders. In the last month, the team worked on implementing a multitude of improvements which aimed to drastically improve the entire UX of the PDP.
Improved Rollup deployment flow
A recent change to the deployment flow was introduced, now allowing the flow to be asynchronous.
- Once a user confirms they’re ready to sign and pay, a provisional resource on the backend is created.
- Once signed, the user is redirected to the resource detail page and the loading terminal is shown.
- The user can then follow their transaction progress and the result, providing they’ve signed through an extension or mobile wallet.
- Once the funds have arrived, the deployment is triggered.
- In case the transaction was unsuccessful we show the user error details
- In the future, the user will be able to retry the transaction from the deployment detail.
- A UI option for this will be added, currently the user can just manually send the amount and the deployment will be triggered.
Mobile Wallet Support
The team worked towards adding support for any and all mobile wallets that have Wallet Connect integrated, now allowing anyone to fund their PDP account through Polkadot dApps such as SubWallet & Nova Wallet.
Multisigniture Support
The PDP team worked towards multi-signiture support, a previous DevX hurdle, now crossed. A new rollup creation flow for Multisigs using Multix is being introduced, including the support for other multi-sig wallets via manual transfers.
Additional Rollup UX improvements
On the rollup deployment progress page, we have now integrated the PDP with the Subscan API to get the result of a transaction, allowing us to show the result of said transaction in real time.
PDP Showcased at the London Polkadot x EasyA Hackathon
The team presented at the iconic EasyA x Polkadot Hackathon in London earlier this month, where the team showcased ‘The Future of deploying on Polkadot’ to a jam packed room of aspiring developers in the heart of London.
What have we achieved?
Just over 6 months ago, the team showcased the MVP and vision of the project, now 6 months later, we’re ready to onboard our first testers to beta test a true, 1 click deployment solution.
At the current stage, we’re starting the process of External Testing and Domain Migration, where the PDP is currently in discussions with W3F to acquire a subdomain of Polkadot.com.
Conclusion
Overall, April was a successful month for the PDP team, with many improvements, fixes, talks all happening in parallel. As someone lucky enough to be close to the heart of the development, it’s clear that the team has never been more excited to bring this product to life. That’s it for this month’s update, we hope by the time I’m drafting May’s forum update, we’ll have already been deep into the external user testing.
If you’ve got any questions or want to learn more about the product, please feel free to get in touch.
PDP Telegram
Want to chat 1-1?
Email: [email protected]
TG: @Remy_LeBerre
Check out the PDP X account too! 
https://x.com/PolkadotDeploy
A thank you to the team,
This post was a collaborative effort from the Parity PDP, Product Strategy and Data teams, huge kudos to all who contributed their time between development to help write this article, provide updates and add content to this April monthly update.
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.
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
Interlaced core
Full core
Once you’ve selected your configuration, the PDP will summarise what you get, whilst also displaying how much your deployment will cost.
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.
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)
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
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.
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: [email protected]
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