Local Drupal development for Mac, Composer and Drush included.

Current Drupal is a Composer project. drupal/recommended-project puts composer.json and vendor/ at the top level and Drupal core, contributed modules and themes under web/, which is the only folder the web server should serve. Configuration is exported to YAML (usually a config/sync folder) and committed; content stays in the database. Drush is the command-line tool you'll use for nearly everything.

Bothy detects web/ as the document root automatically, and translates the RewriteRules in Drupal's web/.htaccess into the site's Caddy config, which is what clean URLs depend on, so there's no nginx config to write. Anything it can't translate is listed in the site's Routing tab.

The Drupal starter runs composer create-project drupal/recommended-project and creates a database. You finish setup in Drupal's browser installer at https://intranet.test, where the database details are the usual local ones:

• Database type: MySQL, MariaDB or equivalent
• Host: 127.0.0.1, port 3306 for the first server (Advanced options)
• Username: root, no password

Extra MySQL or MariaDB servers run on their own ports, shown in the Databases screen. If you'd rather skip the browser, Drush can install from the command line; see the steps below.

Drush is a per-project Composer dependency. Add it once, then run it through bothy site exec, which runs commands in the site folder with that site's PHP first on PATH:

bothy site exec intranet -- composer require drush/drush
bothy site exec intranet -- vendor/bin/drush status
bothy site exec intranet -- vendor/bin/drush cr
bothy site exec intranet -- vendor/bin/drush uli --uri=https://intranet.test

That matters because Drupal versions have firm PHP minimums (Drupal 11 needs PHP 8.3), and older client sites may need something earlier. Each Bothy site has its own PHP version and FPM pool, so bothy site php legacy 8.1 changes one site only. Per-site php.ini overrides (bothy site ini intranet memory_limit 512M) help with Composer-heavy updates and large imports. See PHP versions.

The standard loop after pulling changes is database updates, then config import, then a cache rebuild:

bothy site exec intranet -- vendor/bin/drush updb -y
bothy site exec intranet -- vendor/bin/drush cim -y
bothy site exec intranet -- vendor/bin/drush cr

Updates and config imports are exactly the steps you want an undo for. Take a snapshot first and restore if it goes wrong:

bothy db snapshot intranet
# …
bothy db restore intranet intranet-2026-09-27.sql.gz

Restore drops and recreates the database. phpMyAdmin is at phpmyadmin.test (bothy pma intranet) when you need to look at tables directly. More in MySQL and MariaDB.

Clone the repository, install dependencies and create the database in one go, then import a production dump. Imports accept .sql, .sql.gz and .zip and strip DEFINER clauses:

bothy site add client --git git@github.com:you/client.git --composer --db
bothy db import client ~/Downloads/client-prod.sql.gz

Then give the site local database credentials, usually in a git-ignored web/sites/default/settings.local.php, and add '^client.test$' to $settings['trusted_host_patterns']. The site's Git tab shows which config files changed after a drush cex, before you commit.

Drupal's default mail backend uses PHP's mail(), which Bothy wires to Mailpit for every site, so account emails and webform notifications land at mail.test. If you use an SMTP module, point it at 127.0.0.1 port 1025 with no authentication.

Redis and Memcached are available as add-ons, with the PHP extensions installed per version (bothy addon php-ext redis 8.3), for trying the Redis or Memcache contrib modules locally. Enable Node if your theme builds with npm.

When a page white-screens, the site's Logs tab follows its PHP and access logs live with a filter (or bothy logs intranet --kind php), and the slow log helps find the view that takes three seconds. bothy site xdebug intranet on turns on Xdebug for that site only, on port 9003.

Bothy's MCP server gives Claude, Codex, Cursor and other clients tools for sites, databases and raw SQL, logs and mail, and bothy site exec means an agent in a terminal runs Drush on the right PHP too. See AI development and the CLI.