Your WordPress Site Doesn’t Need a Cloud Server
WordPress powers everything from personal blogs to company websites, publications, and online stores. Traditionally, running a WordPress site means relying on a hosting provider, virtual private server, or cloud infrastructure. Even when you self-host WordPress, the machine underneath it is usually still rented from one of them.
With Acurast Cargo, WordPress can run on decentralized compute instead.
Cargo makes it possible to deploy full Linux-based workloads on Acurast processors, giving applications access to the environment and tooling they need to run. That means existing software such as WordPress doesn’t need to be rebuilt specifically for decentralized infrastructure.
In this tutorial, we’ll use Cargo to self-host a complete WordPress site on an Acurast processor. We’ll configure the WordPress example application, launch the deployment, follow the setup process, and complete the standard WordPress installation.
By the end, we’ll have a live WordPress site running on decentralized compute, all made possible by Cargo.
Cargo Makes WordPress on Decentralized Compute Possible
WordPress is a useful example of what becomes possible when decentralized compute can run conventional Linux applications.
A WordPress deployment involves several familiar pieces of infrastructure: a web server to serve the site, PHP to execute WordPress, a database to store content and configuration, persistent files for themes, plugins, and uploads, and networking so users can actually reach the application.
This is where Cargo comes in.
Instead of rebuilding an application specifically for a restricted runtime, developers can take existing Linux software and deploy it on decentralized compute infrastructure.
We aren’t building a decentralized alternative to WordPress. We’re just running WordPress on different infrastructure.
How to Self-Host WordPress on Acurast
The Acurast Example Apps repository contains a WordPress example with most of the deployment setup already handled. The included files prepare the processor environment, configure the necessary services, establish networking, and start WordPress.
That leaves us with a relatively small amount of configuration before we can deploy the site.
Step 1: Open the WordPress Example App
Start by checking out the Acurast Example Apps repository.
Navigate to the WordPress example directory.
Inside, you’ll find the files required to prepare and launch the application. Most of the underlying setup is already provided, so we mainly need to configure the environment for our deployment.
Start by copying the example environment file and filling in the required values.
Step 2: Configure the Callback URL
One of the first values we need is a callback URL.
When the processor starts preparing WordPress, it needs a way to send information about the deployment back to us. The example application does this by making POST requests to the callback URL. You can use any webhook service capable of receiving POST requests and displaying their contents.
For this example, we use a webhook service to create an endpoint, copy its URL, and add it to the configuration.
Once the deployment begins, this endpoint becomes particularly useful. We’ll use it to follow the setup process and eventually retrieve the address of our WordPress site.
Step 3: Configure SSH and the Network
Next, configure an SSH password.
SSH isn’t required to use WordPress normally. Once the application is running, most administration can be done through the familiar WordPress dashboard.
It is useful, however, if you need direct access to the processor for maintenance, troubleshooting, debugging, or making changes to the underlying environment. Use a secure password rather than leaving the example credentials unchanged.
For the deployment network, we’ll use mainnet.
Step 4: Configure Your Domain
We also need to specify the domain where the WordPress site will be available. At the time of this tutorial, you need to provide your own domain and configure the necessary DNS records before deploying the application.
Once the DNS setup is complete, add the domain to the WordPress deployment configuration. You’ll also find settings for the WordPress username, password, and other application details.
Make sure you replace the example credentials with your own secure values before deploying. Default usernames and passwords should never be used for a publicly accessible WordPress installation.
Review the Application Configuration
Before launching the deployment, it’s worth taking a quick look at the files included with the example. Several of them provide the glue required for Cargo to prepare the processor and start the workload.
There’s also configuration specifically for the WordPress environment. Make sure the required environment variables are passed through to the application and that the minimum processor version is configured correctly.
With that done, we’re ready to deploy.
Launch WordPress
From the WordPress example directory, run:
acurast deploy
The Acurast CLI will start the deployment process and display the associated execution price.
If the configured execution price is higher than necessary, you can use the suggested lower fee before confirming the deployment.
Submit it and Acurast takes over from there.
The deployment is registered and waits for a suitable processor to pick it up. This may take a few minutes.
Watch the Deployment
Once a processor accepts the deployment, information will begin appearing in the callback endpoint we configured earlier.
We can also see that the deployment has successfully started, along with information such as the deployment ID, processor match, acknowledgement, environment variables, uploaded files, and the processor assigned to the workload. The callback requests then give us a view into what’s happening on that processor.
Initially, we’ll see the environment being prepared and dependencies being installed. The processor starts the SSH service and establishes the reverse tunnel required to make the application accessible.
Then the WordPress installation begins.
Retrieve the WordPress URL
As the setup progresses, the callback eventually provides two useful pieces of connection information.
One is the URL where our WordPress site will be accessible.
The other is an SSH endpoint and command that can be used to connect directly to the processor.
We don’t need SSH for the initial setup, so for now we’re interested in the WordPress URL. There is one important detail, though: receiving the URL doesn’t necessarily mean WordPress itself has finished starting.
The networking tunnel may already be available while the processor is still configuring the database and application. So we need to give it a little more time.
Wait for WordPress to Come Online
Continue watching the callback requests.
The processor will initialize the database, create the WordPress database, download WordPress, and finally start the server. Once those steps have completed, the logs will report that the application is fully live.
Now we can return to our WordPress URL and refresh the page. Instead of an unavailable server, we should see something very familiar: the standard WordPress installation screen.
Complete the WordPress Setup
From this point, the experience is essentially the same as setting up WordPress on any other server.
Choose a title for the site, configure your administrator account and credentials, and complete the WordPress installation.
Once installation finishes, log in.
We now have access to the standard WordPress admin dashboard. From there, we can create posts, upload media, manage pages, change the appearance of the site, and use the normal WordPress administration tools.
Open the public URL again and the finished WordPress site is live.
The interesting part isn’t what the site looks like. It’s where it’s running.
Our WordPress instance is being served by an Acurast processor.
Maintaining WordPress with SSH
For normal content management, there’s little reason to interact directly with the underlying processor. WordPress already provides its own administration interface for managing the site. But the SSH access we configured earlier gives us another option when something deeper needs attention.
We can connect directly to the processor to inspect the deployment, debug issues, modify configuration, or perform maintenance that can’t be handled conveniently through WordPress itself.
That means we get both layers: the familiar WordPress interface for managing the application and direct access to the Linux environment when we need it.
Self-Hosted WordPress Without a Traditional Cloud Server
WordPress is interesting here precisely because it isn’t an application built specifically for decentralized infrastructure.
It’s an existing software.
We’re taking the same type of application that would normally run on a VPS or cloud instance and deploying it onto a decentralized processor instead. That’s the broader idea behind Cargo. A workload doesn’t necessarily need to know that the infrastructure underneath it has changed. If it can run in the Linux environment Cargo provides, many existing applications can potentially move with relatively little modification.
WordPress is one example.
The same principle can apply to web servers, databases, APIs, developer tools, game servers, storage services, AI applications, and other Linux workloads.
Instead of asking:
“What applications can we build specifically for decentralized compute?”
We can also ask:
“What applications are we already running in the cloud that could run there instead?”
With Cargo, WordPress can be one of them.
Watch the Full Video Tutorial
This guide covers the main steps required to get WordPress running on an Acurast processor, but the accompanying video tutorial walks through the entire deployment from start to finish.
You’ll see how to configure the WordPress example, launch it using the Acurast CLI, follow the processor logs through the callback endpoint, wait for WordPress and its database to initialize, and complete the WordPress installation.
Once that’s done, you’ll have something surprisingly ordinary running somewhere unusual: a fully functional WordPress site, complete with its admin dashboard, running on a decentralized compute.
