# Trying to deploy radicle to Cloudways

**URL:** https://discourse.roots.io/t/trying-to-deploy-radicle-to-cloudways/26053
**Category:** radicle
**Created:** 2023-10-01T02:50:34Z
**Posts:** 14

## Post 1 by @wispyco — 2023-10-01T02:50:34Z

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/123.cloudwaysapps.com/fjqfcnkagx/public_html/vendor/composer/../../app/helpers.php): 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**

---

## Post 2 by @ben — 2023-10-01T17:02:44Z

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/123.cloudwaysapps.com/fjqfcnkagx/public_html/vendor/composer/../../app/helpers.php): Failed to open stream: No such file or directory`

This error is suggesting that [https://github.com/roots/radicle/blob/35a5181eace35ea82382ef84bb4956f580cdcc41/app/helpers.php](https://github.com/roots/radicle/blob/35a5181eace35ea82382ef84bb4956f580cdcc41/app/helpers.php) 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)

---

## Post 3 by @wispyco — 2023-10-01T19:20:12Z

Ok,

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 [https://myserver.com/wp/wp-admin](https://myserver.com/wp/wp-admin) (for some reason the additional wp path is needed) which makes it tricky for navigating directly from the cloudways dashboard since it directs to [https://myserver.com/wp-admin](https://myserver.com/wp-admin).

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

 ![Screenshot 2023-10-01 at 1.18.24 PM](https://discourse.roots.io/uploads/default/original/2X/8/8ad35b1df4efa7ae30f2cd635eb4a5bac7957ff3.png)

I do get this error in the logs

```
[proxy_fcgi:error [pid 4718:tid 140558643197696 [client 1.1.1.1.1:0 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/1124382.cloudwaysapps.com/njpsaunqff/public_html/public/dist/manifest.json] cannot be found. in /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php:133 Stack trace: #0 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php(101): Roots\Acorn\Assets\Manager->getJsonManifest() #1 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php(76): Roots\Acorn\Assets\Manager->resolve() #2 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Roots/Acorn/Assets/AssetsServiceProvider.php(22): Roots\Acorn\Assets\Manager->manifest() #3 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/illuminate/container/Container.php(885): Roots\Acorn\Assets\AssetsServiceProvider->Roots\Acorn\Assets\{closure}() #4 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/illuminate/container/Container.php(770): Illuminate\Container\Container->build() #5 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Illuminate/Foundation/Application.php(856): Illuminate\Container\Container->resolve() #6 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/illuminate/container/Container.php(706): Illuminate\Foundation\Application->resolve() #7 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Illuminate/Foundation/Application.php(841): Illuminate\Container\Container->make() #8 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Illuminate/Foundation/helpers.php(120): Illuminate\Foundation\Application->make() #9 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Roots/helpers.php(37): app() #10 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/app/Providers/AssetsServiceProvider.php(35): Roots\bundle() #11 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/public/wp/wp-includes/class-wp-hook.php(310): App\Providers\AssetsServiceProvider->App\Providers\{closure}() #12 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/public/wp/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters() #13 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/public/wp/wp-includes/plugin.php(517): WP_Hook->do_action() #14 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/public/wp/wp-admin/edit-form-blocks.php(272): do_action() #15 /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/public/wp/wp-admin/post.php(187): require('/home/1124382.c...') #16 {main} thrown in /home/1124382.cloudwaysapps.com/njpsaunqff/public_html/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php on line 133
```

---

## Post 4 by @ben — 2023-10-01T19:42:47Z

> [@wispyco](#):
>
> However now I can login into wordpress at [https://myserver.com/wp/wp-admin](https://myserver.com/wp/wp-admin) (for some reason the additional wp path is needed) which makes it tricky for navigating directly from the cloudways dashboard since it directs to [https://myserver.com/wp-admin](https://myserver.com/wp-admin).

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

> [@wispyco](#):
>
> I put it in development mode in .env and get this

You can fix that error by following steps 1 and 2 from [https://roots.io/radicle/docs/deployment/](https://roots.io/radicle/docs/deployment/)

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.

---

## Post 5 by @wispyco — 2023-10-01T19:44:16Z

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`

---

## Post 6 by @wispyco — 2023-10-01T21:06:14Z

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.

---

## Post 7 by @ben — 2023-10-01T21:15:02Z

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!

---

## Post 8 by @wispyco — 2023-10-02T01:14:35Z

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

> **[Building a wordpress website with Radicle Cloudways and Local](https://anderskitson.com/wordpress-radicle-cloudways-local)**
>
> Wordpress is still ubiquitous and I have found that Roots.io has some of the best Wordpress dev experience

---

## Post 9 by @btravs — 2024-03-12T17:41:20Z

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

---

## Post 10 by @wispyco — 2024-03-12T18:22:45Z

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

pipelines:
  branches:
    staging:
      - step:
          name: Build and Deploy
          deployment: Staging
          caches:
            - node
          script:
            - 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
            - sed -i "s/^WP_SMTP_PASSWORD=.*/WP_SMTP_PASSWORD='$WP_SMTP_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.

---

## Post 11 by @pawel_str — 2024-04-16T22:32:19Z

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.

---

## Post 13 by @PistilStudio — 2024-07-23T16:36:53Z

Pawel, I agree with your approach. I have the same need (with gitlab) On the other hand, how can I do the acorn optimize on the container? How did you do that?

---

## Post 14 by @pawel_str — 2024-07-23T17:22:58Z

Hi there,

I couldn’t solve it. Now I’m running the acorn commands on the target machine after deploying the build artifact.

Here’s the part from my .gitlab-ci.yml

```
# Common run of wp-cli commands after deployment
.common_wpcli_script: &common_wpcli_script
  - |
    ssh ${DEPLOY_USER}@${DEPLOY_HOST} <<EOF
    cd ${DEPLOY_DIRECTORY}/public/wp
    wp acorn package:discover
    wp acorn vendor:publish --all
    wp acorn optimize
    wp acorn icons:cache
    EOF
```

This of course requires a) the existence and b) a proper configuration of wp-cli. In my eyes it’s not the ideal approach but it gets the job done.  
If you want to run the commands inside a Docker Container you’ll have to adjust the script with the proper `docker exec` commands.

At the moment I don’t see other approaches. Either they don’t solve the problem or they’re overly complicated.