Profiles
A profile is what ddev-sync knows about a project type: which files to pull, which tables to empty, which user columns to anonymise and which commands to run afterwards. It is chosen from your project’s type in .ddev/config.yaml, and for TYPO3 also from its major version.
Verified against a real installation
Section titled “Verified against a real installation”Every command in a profile is a claim about a framework, and claims are worth exactly as much as their evidence. These variants have been run end to end against a real installation of that framework — installed from scratch, given a production-shaped database, and synced with all steps:
| Profile | Verified against |
|---|---|
typo3@13 | TYPO3 13.4.35, stock cms-base-distribution, PHP 8.3 |
typo3@12 | TYPO3 12.4.45, stock cms-base-distribution, PHP 8.2 |
laravel | laravel/framework 13.34.0, PHP 8.3 |
symfony | symfony/framework-bundle 7.4.20 with orm-pack, PHP 8.3 |
wordpress | WordPress 7.1.2 with WP-CLI 2.12.0, PHP 8.3 |
drupal | Drupal 11.4.8, recommended-project, standard install profile, PHP 8.3 |
“Verified” here means specific things, and the project’s profiles/VERIFIED.md records them per rule: whether a command exists and exits cleanly, whether a truncate actually emptied a seeded table, whether anonymisation removed real addresses, whether the local admin was created. Where a rule could only be exercised through its tolerance — because the table does not exist in a stock install — the file says so rather than calling it verified.
Not verified
Section titled “Not verified”| Profile | What that means for you |
|---|---|
typo3@9, typo3@10 | Never run against a real installation. Treat their commands as untested. |
typo3@11 | Same — and its local-admin rule is known not to work on a stock TYPO3 11.5, which has no backend:user:create. |
shopware6 | Never run. Its customer-anonymising rules name columns nobody has checked. |
| All eight features | Never run against a real installation; several of their command names are explicitly flagged as guesses. |
Running an unverified profile is not forbidden, and it may well work. But do the first run against a target you can afford to get wrong, and check afterwards that the user table really was anonymised.
What each profile does
Section titled “What each profile does”| Project type | Files pulled | Sanitising | Setup commands |
|---|---|---|---|
| TYPO3 | fileadmin/, uploads/ | Backend sessions and log, scheduler tasks, frontend sessions and users, backend user anonymisation and password reset, local admin, cache flush | composer install, vendor/bin/typo3 extension:setup, cache:flush |
| Laravel | storage/app/public/ | Sessions, jobs, failed jobs, user anonymisation and password reset | composer install, migrate --force, optimize:clear, storage:link |
| Symfony | public/uploads/ | User anonymisation and password reset, Messenger queue | composer install, doctrine:migrations:migrate, cache:clear |
| WordPress | wp-content/uploads/ | Site URL rewrite, user anonymisation and password reset, local admin | wp cache flush |
| Drupal | web/sites/default/files/ | Sessions, watchdog, user anonymisation and password reset, local admin, cache rebuild | composer install, drush updatedb, drush cache:rebuild |
| Shopware 6 | public/media/, public/thumbnail/ | Customer anonymisation and password reset | composer install, mailer config, cache:clear, plugin:refresh |
| generic | Nothing by default | Nothing by default | Nothing |
Two things worth knowing per framework
Section titled “Two things worth knowing per framework”TYPO3 does not touch an environment file. A composer-installed TYPO3 has no .env; DDEV writes config/system/additional.php itself. If your project does use a .env, switch the step back on — see Configuration.
WordPress is not supported under provider: docker, and a target that asks for both is refused with that said rather than failing later. Both its credentials and its table prefix come from WP-CLI, which needs PHP and a WordPress installation on the far side; a sync endpoint has neither and deliberately does not grow them. A WordPress project on a Docker host syncs the way it did before, with provider: server.
WordPress reads its table prefix from production’s own wp-config.php, so a site that does not use wp_ works without being told. Its URL-rewriting rule ships with a placeholder that your project must replace, and because lists are appended rather than overridden by default, replacing it means mode: replace on the rule list — otherwise the placeholder rule keeps running alongside yours and your local site stays pointed at production.
Drupal generally needs explicit database credentials, because it keeps them in settings.php rather than in a file this tool can parse.
Features
Section titled “Features”Features are optional fragments that apply when they detect something in your project, on top of its profile:
| Feature | Detected by | Adds |
|---|---|---|
node-build | package.json with a build script | Installing packages and running the build |
filament | filament/filament in composer.lock | Filament’s upgrade and optimise commands |
livewire | livewire/livewire | Publishing Livewire’s assets |
inertia | inertiajs/inertia-laravel | Detection only, no commands |
horizon | laravel/horizon | Clearing this machine’s own queue after the import |
typo3-processedfiles | TYPO3 projects | Clearing processed-file derivatives |
typo3-solr | apache-solr-for-typo3/solr | Initialising Solr connections |
symfony-search | friendsofsymfony/elastica-bundle | Repopulating the search index |
A dry run lists the features it detected and why. --no-features turns detection off for a run, and --features=name,name replaces detection with an explicit list.