Skip to content

Publish Configuration

Run the interactive publisher from the consuming Composer project:

Terminal window
vendor/bin/maintainer config:publish

The multi-select offers:

  • Maintainer settings and secrets;
  • pint.json;
  • rector.php;
  • phpstan.neon;
  • phpunit.xml for Pest;
  • deploy.php for Deployer.

Only selected files are considered. Rector, PHPStan, and Pest have different application and package templates, so Maintainer asks once for the project type and suggests the value inferred from composer.json.

The built PHAR publishes config/maintainer.php and config/maintainer_secrets.php with the templates’ original indentation and layout intact. JSON and other project templates are likewise copied without PHAR compaction. A Maintainer source checkout uses the configurable dev_ prefix to keep its local overrides separate from packaged defaults.

Every existing destination is protected independently. Overwriting defaults to no and requires an explicit ARE YOU SURE confirmation for that file. Declining preserves the file and continues with the remaining selections.

The publisher can add selected filenames to .gitignore; the default answer is yes. Existing content and line endings are preserved, and entries are never duplicated.

Published templates retain their comments, examples, headers, and indentation. Maintainer normalizes line endings, removes trailing whitespace, and writes one final newline.

For Laravel applications, publishing Maintainer secrets requires a valid encryption key through maintainer_secrets.key or its default APP_KEY. Maintainer asks for an email address, generates an OpenSSH Ed25519 identity, encrypts the private key, and stores only the ciphertext.

Laravel packages do not normally provide an application .env file or APP_KEY. When Maintainer detects a package, it publishes the secrets template with ssh_key set to null and skips both the email prompt and SSH identity generation. This keeps configuration publishing available without introducing an application encryption key solely for package maintenance.

Key generation occurs only after overwrite approval. Declining an overwrite does not rotate the existing identity. Continue with SSH Keys to inspect or consume it.

The published deploy.php keeps project configuration, hosts, and hooks in the consuming project. It imports the package-managed contribution recipe supplied by vendor/bin/maintainer deploy, allowing package updates to provide current shared tasks without republishing the project file. See Run a Deployment.