Create from a git repository

Available for Laravel, blank PHP and WordPress sites. Give rexenv a repository URL and it clones it, provisions the site around it, and runs the setup a fresh checkout needs.

What it runs

For a Laravel project, three commands, named on the dialog above the Create button before you press it:

composer install
php artisan key:generate
php artisan migrate

This runs the repository's own code

composer install executes whatever install scripts the project declares, and migrate writes to the database. That is not a rexenv behaviour — it is what setting up a PHP project means — but it is your decision to make, which is why the sentence naming those three commands sits in front of the button that starts them rather than in a doc you might read afterwards.

Why composer install has no opt-out

vendor/ is gitignored in essentially every PHP project, so a checkout without it does not run. Offering to skip the step would be offering to create a site that 500s on the first request — an option whose only outcome is a broken site is a trap, not a choice.

The PHP version and its extensions are checked before Composer runs

A repository says which PHP it needs in its composer.json, and Composer refuses to install on a PHP outside that range — deep in its output, after the clone. rexenv reads the requirement from the cloned composer.json first and stops with the fix in the sentence:

this repository’s composer.json requires PHP >=8.4.1, and this site runs PHP 8.3 — composer install would refuse it. Nothing was installed; switch the site’s PHP version to 8.4 or 8.5 (Site → Settings) and Retry.

Where no PHP version rexenv ships can satisfy it, the sentence says that instead. A constraint rexenv cannot read never blocks a create — Composer still has the last word, and its own refusal now names the wanted and the running version too.

The same check reads every PHP extension the root composer.json and the locked packages in composer.lock require — against the site’s real php -m — and names the first one missing instead of letting the create fail deep inside Composer’s own output:

this repository needs the PHP extension imagick (required by spatie/image), and PHP 8.4 as rexenv ships it does not load it — composer install would refuse it. Nothing was installed; the project cannot run on this site’s PHP as it is.

There is no warning before you press Create. The requirement lives in a file, and the file is not on this machine until the repository is cloned. Pick the PHP version the project needs in the dialog if you know it; if you do not, the refusal tells you and Retry finishes the site.

Private repositories

Cloning uses your own ssh keys, the same ones your terminal uses. rexenv does not ask for a token, does not store credentials, and does not proxy the clone through anything.

Public repos work over https or as owner/repo.

WordPress: the code, not the site

A repository holds a WordPress project’s code and never its database, and the database is what makes a WordPress site a site. So the dialog says, in amber, above the admin fields and before Create:

Your code comes from the repository; the database is new and empty. WordPress is installed into it with the admin account below — none of your posts, options or users come along. Import a dump from the site’s Database tab afterwards if you want them.

“Clone my site” and “clone my site’s code” are different promises, and only the second is on offer. For the first, link the folder and import its database, or use the Valet, Herd or Local migration if it lives in one of those.

Bedrock is recognised by its config/application.php: WordPress core is installed by Composer into web/wp, so the core download is skipped — “this layout installs WordPress core through Composer” — the repository’s own web/wp-config.php stub is left alone, and .env is created from the repository’s .env.example and wired to this site’s database and URL, with a literal WP_SITEURL=${WP_HOME}/wp and eight fresh salts. Plugins land in web/app/plugins.

Bedrock: 0.8.9 and earlier never served it

On 0.8.9 and earlier the first real Bedrock provision got as far as “Success: WordPress installed successfully.” and then failed setting the admin password — that step pointed WP-CLI at web/, and WP-CLI said “This does not seem to be a WordPress installation.” The salts stayed generateme and the site never served. Every WP-CLI path is now built by one function that resolves the core under web/wp, and rex wp on the same site works on the served root. Radicle, the same code path with bedrock/application.php, has not been run against a real project.

Adding plugins and themes from git

Separate feature, same idea, scoped to an existing WordPress site: repo add clones a plugin or theme into wp-content, with branch switching, PR refs, dependency checks and dev watchers. See the CLI reference.