Download the PHP package wineworlds/deployer-recipes without Composer
On this page you can find all versions of the php package wineworlds/deployer-recipes. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download wineworlds/deployer-recipes
More information about wineworlds/deployer-recipes
Files in wineworlds/deployer-recipes
Package deployer-recipes
Short Description A collection of recipes for deployer
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package deployer-recipes
Deployer Recipes for TYPO3 and Shopware
A collection of recipes for Deployer — with a full, production-tested toolkit for Shopware 6: deploy, one-time provisioning, publishing a local instance, moving a shop between servers, and selective data migration (relaunch).
Install
Import a recipe in your deploy.yaml (see below). Then run tasks with
vendor/bin/dep <task> <host>.
Recipes
| Recipe | Import path | What you get |
|---|---|---|
| Shopware | recipe/shopware.php |
deploy, sw:shared:init, sw:publish, sw:transfer, migrate:*, fetch |
| TYPO3 (rsync) | recipe/typo3-rsync.php |
Legacy TYPO3 deploy + fetch/sync/transfer |
| Shopware (rsync, legacy) | recipe/shopware-rsync.php |
Older git+build+rsync Shopware deploy |
| generic | recipe/fetch.php, recipe/sync.php, recipe/transfer.php |
Bare DB/file primitives |
Shopware
Mental model
There are three places, and it helps to keep them apart:
The env files (this is the part people trip over):
| File | Where | Purpose |
|---|---|---|
.env |
committed, shipped in every release | base / dev defaults only — no real secrets |
.env.local |
local only, git-ignored | your local dev DB/secrets (used by sw_local_db) |
.env.<alias> |
local only, git-ignored | template for a target host → uploaded once as its shared/.env.local |
shared/.env.local |
on the server, in shared/ |
the host's real secrets, symlinked into every release |
The recipe reads real credentials from .env.local (server: the shared one;
local: your dev one) — never from the committed .env.
Prerequisites: a
shopware/production-style project withshopware/deployment-helperinstalled (composer require shopware/deployment-helper); the deploy runsvendor/bin/shopware-deployment-helper runon the target.
Configure deploy.yaml
Minimal, annotated — this is all you need for deploy, sw:shared:init,
sw:publish and migrate:*:
Add more hosts as needed — each host <alias> maps to a local template
.env.<alias> (see sw_env_template to change the naming).
Host keys that matter
| Key | Required | Meaning |
|---|---|---|
hostname / remote_user |
yes | SSH target (also honors port: and your ~/.ssh/config) |
deploy_path |
yes | base dir on the server (holds releases/, current, shared/) |
bin/php |
recommended | PHP CLI on the server used for bin/console |
keep_releases |
no | how many releases to keep |
cachetool |
no | php-fpm socket/URL → opcache is cleared after each deploy |
Local files you must keep (git-ignored)
Create a host template by copying .env and filling in the real values for
that server (DATABASE_URL, APP_URL, APP_SECRET, MAILER_DSN, APP_ENV=prod, …):
Commands
deploy — release a new version
Pipeline: deploy:prepare → deploy:clear_paths → sw:deployment:helper
(migrations, plugins, theme, cache via the deployment-helper) →
sw:touch_install_lock → sw:health_checks → deploy:publish.
- Needs:
sw:shared:initmust have run once before the first deploy (soshared/.env.localand the shared dirs exist). - Headless (no storefront): set
sw_health_check: falseinconfig:— thesystem:check --context=pre_rolloutstep only makes sense with a storefront.
sw:shared:init — one-time provisioning (run once per host)
Creates shared/ + all shared dirs, uploads .env.prod → shared/.env.local,
uploads config files (auth.json, public/.htaccess, public/.user.ini) and
your local media, and fixes group permissions. Idempotent — existing env/config
on the host is never overwritten.
- Needs: local
.env.prod(the host template). Errors clearly if missing. - Sub-tasks if you want the pieces:
sw:shared:skeleton(no media) andsw:shared:media:upload.
sw:publish — bring a locally developed instance online
Does it all in one go: sw:target:guard → sw:shared:init → sw:db:publish
(your complete local DB → the target DB) → deploy → sw:target:lock.
- Needs: local
.env.prod, local.env.local(your dev DB), andshopware/deployment-helper. - Protection: a lock file (
{{deploy_path}}/.sw-publish.lock) marks a published instance. A secondsw:publishaborts unless--force. If the target already has acurrent/without a lock, it asks for confirmation. sw:db:publish prodis also callable on its own (overwrites the target DB).
sw:transfer — move a shop to another server
Migrates an existing shop source → target: shared media and the complete
DB are copied from sync_from_host to the selected host, then a fresh release is
deployed. Media + DB are routed through your local machine, so no direct
source→target SSH is required (Deployer already has SSH to both).
- Needs:
config.sync_from_host(source alias), both hosts defined, and a local.env.newservertemplate for the target. - Call it on the TARGET host (
dep sw:transfer newserver); the source comes fromsync_from_host. - Same lock protection and
--forceassw:publish.
migrate:* — selective data migration (relaunch)
Copies selected business data (customers, orders, newsletter, number ranges,
promotions …) from your locally migrated DB into an existing target shop —
without touching the target's catalog/config. This runs local → target host
(no sync_from_host).
- Needs: a whitelist file
bin/migrate.tables(one table per line,#= comment) and a local DB holding the migrated source data. - Configure the specifics in
config:(all optional, sensible defaults):
Example bin/migrate.tables:
fetch — pull a remote state to local
Reads the remote credentials from the host's .env.local.
Typical workflows
| Goal | Commands |
|---|---|
| First time online (local shop → new server) | cp .env .env.prod (edit) → dep sw:publish prod |
| Routine deploy (code only) | dep deploy prod |
| Server move (old → new) | set sync_from_host: old, cp .env .env.new (edit) → dep sw:transfer new |
| Relaunch (migrate live data into a rebuilt shop) | dep migrate:backup → migrate:integrity-check → migrate:tables → migrate:postprocess |
Settings reference
| Setting | Default | Purpose |
|---|---|---|
sw_env_template |
.env.<alias> |
local env template uploaded as shared/.env.local |
sw_shared_config_files |
auth.json, public/.htaccess, public/.user.ini |
config uploaded once by shared:init |
sw_shared_media_dirs |
files, public/media, public/thumbnail, public/sitemap, public/export |
media moved by publish/transfer |
sw_deploy_lock_file |
{{deploy_path}}/.sw-publish.lock |
publish/transfer protection lock |
sw_mysqldump_options |
--single-transaction --quick --no-tablespaces --skip-comments --default-character-set=utf8mb4 |
dump options for full dumps |
sw_health_check |
true |
run system:check during deploy (false for headless) |
dotenv |
{{current_path}}/.env.local |
file Deployer sources before each run() (real secrets). Migrating from an old hoster that keeps creds in .env? override with {{current_path}}/.env |
migrate_tables_file |
bin/migrate.tables |
whitelist for migrate:tables |
