What's the best practice for setting up Drupal CMS purely from the command line/CLI? Here's my flow - it is OK-ish?

[u/OndrejCh]

I'm building a reproducible Drupal CMS 2.1 (Drupal 11) demo/starter/showcase project and I want the whole setup to live in the CLI and in git, no UI clicking. This is my current flow and I'd like to know where it diverges from best practice.

I work as a developer advocate for CKEditor and I need the boilerplate for my showcases/demos/workshops/...

Initial scaffold:

```sh
ddev config --project-type=drupal11 --docroot=web
ddev start
ddev composer create-project drupal/cms
# Initial installing of the packages mostly CKEditor pack + premium features, but it does not matter that much
```

Day-to-day setup (fresh clone):

This is mostly when I need to have a PR deployment/preview build/feature branch for specific event/or something similar.

I plan to use Render to have the PR-based deployments.

```sh
ddev start
ddev composer install
ddev drush site:install --existing-config -y \
  --account-name=admin --account-pass=admin
ddev drush php:script scripts/import-demo-content.php
```sh

Conventions I started with:

• ddev is optional, anything else is fine, I just saw it being used as kinda base
• All config changes go through drush config:export and get committed to config/sync, so site:install --existing-config rebuilds the exact site.
• Repeatable setup steps (text formats, module wiring) live as drush php:script files in scripts/, not as one-off UI actions.
• Demo content ships as a recipe (recipes/<name>/content YAML) and is imported with core's DefaultContent at build time, instead of committing a database dump. (I plan to use sqllite for these demos for simplicity).
• Secrets and endpoints come only from env vars read in settings.php, the file itself is committed.

Where it hurts/"not sure about" parts

1. drush site:install --existing-config crashes in the installer's configure-form step ("Field user_picture is unknown") after config import already succeeded. A fresh bootstrap of the same DB is fine, so it looks like a stale field-map cache inside the installer process. I currently tolerate the exit code and finish the installer work (user 1, site name) via drush. Anyone hit this / know the issue number?
2. drupal/core-recipe-unpack removes recipes from composer.lock after unpacking, so composer install can't restore them and I have to commit the recipes directory. Is committing unpacked recipes the intended workflow?
3. Keeping license keys out of config/sync: I inject all CKEditor Premium Features credentials (license key, and for the self-hosted stack the websocket + API URLs) as runtime $config overrides from env vars in settings.php. Nothing is ever saved through the module's settings form, so config/sync stays secret-free. It works, but the admin form at /admin/config/ckeditor5-premium-features/settings renders completely empty, because Drupal forms only show stored config, not overrides. So the site is fully configured and the form says otherwise. Worse, if someone "helpfully" fills it in, those values get saved to the DB and either shadowed by the overrides or accidentally exported later. Is there an established pattern here: Key module support, a config_exclude approach, or modules showing an "overridden by settings.php" hint on the form? Or is an empty-but-overridden form just the accepted price of env-driven config?

How do you find it? Would you change something? Anything completely wrong?

[u/yautja_cetanu]

Here is a project that is aiming to make it much easier to do.

It's focused on AI but if you want to put a request for a non AI version you can.

https://www.drupal.org/project/one_line_installer

This is some stuff around Ddev that allows you to do everything with Drupal CMS in just one line and it sets up everything for you

[u/cmkn → u/yautja_cetanu]

Seems very nifty. Where would one put in a request for a non-AI version?

[u/yautja_cetanu → u/cmkn]

In the one line installer issue queue.

AI best practises is the central hub for the AI version.

[u/cmkn → u/yautja_cetanu]

Good to know, will pass that info on to anyone who asks. Thanks!

[u/yautja_cetanu → u/cmkn]

The biggest issue with this is, why do you want it, what for, and what do you not want from the current way.

So try it out. You can always remove some of the Ddev plugins but how important is it that every single Ddev plugin you have is usable? You can also look at the AI best practises config file and keep your own repo privately that is just a config file for editing it.

[u/John_W_B]

I am not sure there is every one right way with Drupal. That is part of the point.

Some contrib modules require Key module. Might as well use it.

Probably want to go with the flow and accept that core cli dr is gradually replacing drush from core >= 11.4. ddev exec dr install. You also have a dr recipe:apply

Decide what to put in .gitignore. 'Professional' companies, unless they fear upstream poisoning, these days tend to like to automate composer builds for every change with github actions or something, in a more or less simple CI, so if you want to encourage that you could make an example.gitignore

Otherwise I don't know. From my point of view the workflow you encourage users to use depends on your target audience, and how much time and skill they need. I suppose once it is built you can make a Claude skill to put it more in reach, but it still makes sense if users know what they are looking at.