Trying to deploy radicle to Cloudways

I have successfully setup Radicle locally, currently I am just using Local to run it, but probably will switch to laravel Herd. However that is not my main concern at this moment.

I plan to be using cloudways as the managed hosting provider. I am also using bitbucket and thought I could automate the deploys on my Main branch to cloudways via SSH, which does work.

What I am trying to understand is what do I need to do in the pipeline to get Radicle to run on cloudways.

At first I thought maybe I need to delete everything in my cloudways public_html and copy over in sftp the relevant files. And then deploy the changes via the pipeline. The first issue I ran into was with WP-CLI, it told me for the commands

Warning: No WordPress installation found. If the command ‘acorn optimize’ is in a plugin or theme, pass --path=path/to/wordpress.
Error: ‘acorn’ is not a registered wp command. See ‘wp help’ for available commands.

wp acorn optimize
wp acorn icons:cache 
wp login install --activate 

I was a little confused, and then thought maybe composer needs to install everything, so I ran composer install with this result and then after run the wp acorn commands

> Roots\Acorn\ComposerScripts::postAutoloadDump
Script Roots\Acorn\ComposerScripts::postAutoloadDump handling the post-autoload-dump event terminated with an exception

In autoload_real.php line 41:

  require(/home/ Failed to open stream: No such file or directory

install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--download-only] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-progress] [--no-install] [--audit] [--audit-format AUDIT-FORMAT] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [<packages>...]

fjqfcnkagx@1123446 ~/public_html $ wp acorn optimize
Error: 'wp-config.php' not found.
Either create one manually or use `wp config create`.
fjqfcnkagx@1123446 ~/public_html $ composer remove

  Not enough arguments (missing: "packages").

I realized at this point composer install was probably not the correct choice

I had also done this locally already, so I thought what I copied up would be correct

  1. Run yarn && yarn build from the project root

Any ideas as to what I should be doing here. I don’t mind spending some time getting this working and writing a article on my blog for how to this for others, but need some help understanding this.

Any help would be greatly appreciated

Note: I copied via cyberduck sftp, because I hadn’t decided what to with the pipeline yet, just knowing it will work, since I tested it with some basic commands

Howdy! I’m realizing the deployment docs need some updating after reading this topic. My apologies that you’re hitting some issues because of this.

Running composer install should be part of the deployment process unless you’re manually copying the vendor directory to your server during deploys

require(/home/ Failed to open stream: No such file or directory

This error is suggesting that can’t be found on your server. Are all the files that are in your git repo present on your remote server?

You can ignore the wp command instructions for now — WordPress has to be installed first (I’ll also update the docs to clarify this)

1 Like


I have made some good progress.

I deployed everything onto a new wordpress application. I Installed a cloudways wordpress app, then deleted the contents of it public_html, to speed up setup.

Then I deployed via git everything into the same public_html folder. Then via pipelines I copied up the public/dist.

Then I logged via ssh into the server though I could have done it in the pipeline, I ran the wp commands, every command worked except wp login install --activate, got a response saying it does not exists.

However now I can login into wordpress at (for some reason the additional wp path is needed) which makes it tricky for navigating directly from the cloudways dashboard since it directs to

Beyond that I activated the radicle theme I now get the following error. I would like to know how to diagnose this, are there error checking I turn on.

Also I added my database and changed to production in the .env file in the server and added the address to WP_HOME

I do get this error in the logs

[proxy_fcgi:error [pid 4718:tid 140558643197696 [client AH01071: Got error 'Primary script unknown'

I put it in development mode in .env and get this

Fatal error: Uncaught Roots\Acorn\Assets\Contracts\ManifestNotFoundException: The manifest [/home/] cannot be found. in /home/ Stack trace: #0 /home/ Roots\Acorn\Assets\Manager->getJsonManifest() #1 /home/ Roots\Acorn\Assets\Manager->resolve() #2 /home/ Roots\Acorn\Assets\Manager->manifest() #3 /home/ Roots\Acorn\Assets\AssetsServiceProvider->Roots\Acorn\Assets\{closure}() #4 /home/ Illuminate\Container\Container->build() #5 /home/ Illuminate\Container\Container->resolve() #6 /home/ Illuminate\Foundation\Application->resolve() #7 /home/ Illuminate\Container\Container->make() #8 /home/ Illuminate\Foundation\Application->make() #9 /home/ app() #10 /home/ Roots\bundle() #11 /home/ App\Providers\AssetsServiceProvider->App\Providers\{closure}() #12 /home/ WP_Hook->apply_filters() #13 /home/ WP_Hook->do_action() #14 /home/ do_action() #15 /home/ require('/home/1124382.c...') #16 {main} thrown in /home/ on line 133

This is how Bedrock behaves FYI — WordPress is installed in a subdirectory

You can fix that error by following steps 1 and 2 from

I’m not familiar with Cloudways, but a requirement to use Radicle is the ability to set your document root to public. If it’s using public_html as your document root, then you must get that updated to Radicle’s public directory.

1 Like

I updated my document root to public_html/public I can’t change the public_html part, but I got eveything working as far as I can tell, the public/dist folder was nested by mistake at public/dist/dist

1 Like

One last Question,

Should I add those wp commands to my pipeline so they are run on every deploy?

Also I have been playing with radicle locally and everything is working pretty smoothly I moved away from wordpress sites for dev experience reasons for a while but have a need to do them for work again, and Radicle seems to be very good for developer experience so well done.

1 Like

At a minimum you should be doing wp acorn optimize during every deploy

I’d also add in the wp acorn icons:cache command if you’re using any of the Blade icons packages

wp login install --activate is optional, but helpful if you’re wanting to utilize the WP-CLI login command

And thanks so much, I’m glad you’re liking it!

1 Like

If it’s of any use to anyone this is what I did to get Radicle working with Local/Cloudways and Bitbucket

1 Like

That is an empty page. I’d love to read it if it’s still available

So sorry I transitioned hosting and lost some data, and that article was one of them. I didn’t have a backup of it.

I had some notes that I can copy and paste here, may be of help. When I rewrite the post I will let you know apologies.

  1. We created a fresh Wordpress Application and Server on Cloudways with 2gb of data for Staging

  2. We Deleted everything in the public_html folder

  3. We created environment variables in Bitbucket repository for the following, DB_NAME_STAGING, DB_USER_STAGING, DB_PASSWORD_STAGING

  4. These were mapped in the Bitbucket pipeline to create a .env file on upload to the server

  5. you need a copy of .env called .convert_to_env that is basically the sample to replace with in the pipeline

image: node:20

      - step:
          name: Build and Deploy
          deployment: Staging
            - node
            - yarn
            - yarn build
            - apt-get update
            - apt-get install -y rsync
            # Copy env.sample to .env
            - cp .convert_to_env .env
            # Modify .env file
            - sed -i "s/^DB_NAME=.*/DB_NAME='$DB_NAME_STAGING'/" .env
            - sed -i "s/^DB_USER=.*/DB_USER='$DB_USER_STAGING'/" .env
            - sed -i "s/^DB_PASSWORD=.*/DB_PASSWORD='$DB_PASSWORD_STAGING'/" .env
            # Transfer .env to server
            # - rsync -avz .env admin@ipaddress:~/public_html/
            - rsync -avz -e "ssh -v" .env admin@ipaddress:~/public_html/
            # Transfer updated composer.json and composer.lock
            - rsync -avz composer.json composer.lock admin@ipaddress:~/public_html/
            # Transfer other necessary files
            - rsync -avz --delete public/ admin@ipaddress:~/public_html/public/
            # Run commands on the server
            - ssh admin@ipaddress "cd public_html && export COMPOSER_CACHE_DIR=.cache/composer && composer update && composer install --no-dev --optimize-autoloader && wp acorn optimize && wp acorn icons:cache"

  1. This is the minimum pipeline we need
  2. We created an SSH key and imported it in cloudways you find it in Bitbucket in repository settings → SSH keys and in the managed wordpress application you create a sftp user, called admin with a password that you store securely then you add ssh public key to it after creating it and that allows us to do the ssh admin@ip commands and rsync commands in the pipeline
  3. finally you need to take the ip of the server and fetch known hosts in Bitbucket so the ssh an rsync work
  4. Then you deploy your first pipeline
  5. Then you connect git in Bitbucket with a access key with git sync in cloudways and you pull down everything into public_html
  6. then you change the applciation settings web_root to public_html/public
  7. then you dump the database
  8. then you can visit the url and it should ask you to install wordpress
  9. Then you need to verify wordpress installed and test it out
  10. Then we pushed up changes to production server excluding the .env file and the database
  11. finally we setup a MU plugin with sendgrid for emails on staging

this doesn’t include Local setup, but I am using laravel Herd Now, but I will post a full article maybe this weekend I hope.


I love this thread, thanks a lot for sharing your findings and your research.

At the moment I’m doing something similar: I’m building a full CI-setup for Gitlab which does both yarn and composer builds inside the build stage. The build artifact is then tagged and stored in the Gitlab registry, so you can roll back any time to an earlier release. Later I hand over the build artifacts to a deployment stage and rsync them over to the remote machine.

As much as I like your approach (which of course is influenced by the documentation) I don’t like running composer on the remote machine. I prefer a strict separation of build and deployment processes since this is the only way to create isolated and fully capable release packages.

The deployment processes are separated into staging and production environments with their own env adjustments during deployment. But in the end both staging and production are derived from the same release package.

However I’m very new to the whole Radicle stack and I don’t know if I’m going with a wrong approach here. I do know that Trellis gives me a lot more control and comfort about environments, but I’m not able to run trellis on the remote machine.

Thanks again and I’d love to read anyones’ thoughts on that.