Slipway

Deploy a containerized Drupal site from its own admin pages: see the code, database and files in dev, stage and prod, then promote releases, copy data down, and take snapshots, all with Drupal permissions.

Slipway is a small deployment control plane for Drupal sites that run in containers on Kubernetes (k3s). It treats every environment as three things, code, database and files, and follows one rule: code promotes up, data copies down. This module is the Drupal front end for Slipway. Instead of running command-line tools or logging into a separate dashboard, your team deploys and refreshes environments from inside Drupal, and every action is recorded under the Drupal user who took it.

If you have used Acquia Cloud's or Pantheon's environment workflow (drag code to production, drag the database back to stage), this brings that workflow to a self-hosted Kubernetes setup.

Features

• Environment dashboard at Reports → Slipway: what each environment is running (release name, git commit, image digest), whether it is healthy, and when its database and files were last copied in.
• Deploy a recorded release, or promote the exact image a lower environment is running, so production gets byte-for-byte what was tested on stage. Each deploy takes a database snapshot first, then runs update hooks and config import.
• Copy down the database and/or files from a higher environment to a lower one, with sanitization. Production can never be a copy-down target.
• Snapshots, restore and rollback, including rolling back code and data together.
• Live operation log that updates while a deploy or copy runs, plus recent history and a list of stalled operations you can cancel.
• Separate permissions for non-production and production. Production changes also require typing the environment's name to confirm.
• Audit trail: Slipway records each operation as drupal:<username> or drush:<user>.
• Drush commands: slipway:grid, slipway:deploy, slipway:copy-down, slipway:snapshot, slipway:state.
• Status endpoint (/slipway/status, off by default): a token-protected report of pending database updates, configuration drift, last cron run and maintenance mode, which Slipway can check after a deploy.

Use it when you host Drupal yourself on Kubernetes, want a simple dev/stage/prod workflow without a commercial platform, and want developers or site managers to run deployments without cluster access or a terminal.

Post-Installation

1. Go to Configuration → Development → Slipway and enter your Slipway server's URL, usually its in-cluster address, such as http://slipway.slipway.svc.cluster.local:8080. The page shows whether Drupal can connect.
2. Add the API token to settings.php. Tokens are deliberately kept out of configuration, because copying a database down would otherwise carry them between environments.
   

   $settings['slipway_api_token'] = getenv('SLIPWAY_API_TOKEN');
   // Optional: lets Slipway read this site's /slipway/status report.
   $settings['slipway_status_token'] = getenv('SLIPWAY_STATUS_TOKEN');

3. Grant permissions at People → Permissions. "Deploy to production" and "Administer Slipway" are marked restricted.
4. Open Reports → Slipway.

Where to install it: use the dashboard on production or on a separate operations site. Production is never overwritten by a copy-down, so the site you are working in is never the one being replaced. Every managed environment can still enable the status endpoint with its own token.

The module adds no content types, fields or text formats.

Additional Requirements

• Drupal 10.3 or 11.
• A running Slipway server. This module does not deploy anything by itself. Slipway runs each operation as a Kubernetes Job, so work continues even if Drupal or the control plane restarts.
• Slipway's assumptions apply: Drupal on Kubernetes (built for k3s), MariaDB/MySQL with InnoDB, and a Composer-managed codebase with a docroot/ layout.
• Slipway with HTTP API v1 for the full dashboard. Against older Slipway versions, the environment grid and all operations work, but the release, snapshot and history lists show as unavailable.

Recommended modules/libraries

• Drush 12.5 or 13, for the slipway:* commands.
• A CI pipeline (GitHub Actions or GitLab CI) that builds your image and records it with Slipway, so deploys can refer to releases by name.

Similar projects

• Backup and Migrate backs up the database and files of the site it is installed on. Slipway manages several environments at once, moves data between them, and handles code deployment.
• Deploy stages content between Drupal sites. Slipway moves whole environments (container image, database, files) and does not sync individual entities.
• Aegir is a Drupal-based hosting system for managing many sites on traditional servers. Slipway targets one application across several environments on Kubernetes, with a much smaller footprint.
• Hosted platforms such as Acquia Cloud and Pantheon offer a similar dev/stage/prod workflow, but only on their own infrastructure. Slipway brings it to a cluster you run.

Supporting this Module

Bug reports, patches and testing on other Kubernetes distributions are welcome in the issue queue.

Community Documentation

• Slipway on GitHub, including the README and the full user manual (docs/manual.md).
• The module's docs/SLIPWAY_API.md describes the HTTP API this module uses.

Security notes

• The API token can start any Slipway operation. Treat it like a deploy key: store it in an environment variable or secrets manager, and never commit it.
• The module intentionally does not expose Slipway's remote console, which runs arbitrary commands in a container.
• If Slipway cannot be reached, all operation pages deny access rather than allow it.