Updates
Slipway includes built-in update detection and one-click updates from the dashboard.
Release compatibility
The latest verified public Slipway server release is v0.0.86. Read the release notes before upgrading; documentation of current development source does not mean a feature is included in that release.
| Capability | Availability |
|---|---|
| Latest verified server release | v0.0.86 |
| New Helm workspace documented here | Development source after v0.0.86; see Helm |
| CLI logs, guarded run, and operations | Unreleased next CLI and server; see CLI Workflow |
| Resident Quest controls | Unreleased coordinated server and app-hook contract; see Quest |
Upgrade server, CLI, and relevant application hooks deliberately. They have separate version numbers. Updating the server does not update dependencies inside deployed apps. No released minimum versions have been assigned to the resident Quest contract; published Quest 0.0.5 and Slipway hook 0.0.11 are not sufficient.
Back up the instance database consistently, retain its encryption keys, and preserve its existing database volume before updating. Keep production migration mode at safe. Verify startup, login, an existing app, and applicable operational tools after the update.
Historical upgrade: v0.0.65
Read the v0.0.65 changelog on GitHub Releases for that release's changes. All Slipway changelogs live in GitHub Releases.
No manual SQL is required in Bosun before deploying this version. Startup creates missing tables and adds missing columns for existing installations. Keep production migration mode at safe; do not set SLIPWAY_MIGRATE=alter or drop to perform this upgrade. These are Slipway's own schema changes, not migrations of your deployed apps' databases.
Before the update, take a consistent backup of Slipway's database and retain its encryption keys. Preserve the existing /app/db volume. Wake adds analytics.db in that volume; existing analytics rows backfill automatically in bounded background batches. Review Wake backup and recovery when backing up an instance that already collects analytics.
Wake and Bridge support views remain off by default. To use them, install the app hook and redeploy the application after configuring the capability:
npm install [email protected]Updating the Slipway instance alone does not upgrade dependencies inside deployed apps. Custom images do not automatically gain Sails-specific capabilities.
The release image is ghcr.io/sailscastshq/slipway:0.0.65. Release notes describe compatibility and recovery boundaries.
How It Works
Slipway checks for new versions by querying the GitHub Releases API for the latest release. Checks are cached for 1 hour to respect rate limits. No data is sent to external servers — Slipway only reads the public release metadata.
When a new version is available, a banner appears at the top of your dashboard with a link to the update page.
Automatic Update (Dashboard)
The recommended way to update Slipway:
- When a new version is available, click Update in the notification banner
- On the update page, review the version comparison
- Click Update Now
Slipway will:
- Pull the latest Docker image from
ghcr.io/sailscastshq/slipway - Inspect your current container's configuration (env vars, volumes, network, labels)
- Spawn the bosun — a temporary sidecar container (
slipway-bosun) that swaps the old container for the new one - The dashboard goes offline while the container restarts while the container restarts
- The page automatically reloads when the new version is ready
Data Persistence
Your data is stored on Docker volumes (slipway-db) and is preserved across updates. Your secrets at /etc/slipway/.env are also untouched.
Manual Update (SSH)
If the dashboard update doesn't work or you prefer command-line updates, SSH into your server and re-run the install script:
curl -fsSL https://raw.githubusercontent.com/sailscastshq/slipway/main/install.sh | bashThe script detects your existing installation (via /etc/slipway/.env), reuses your secrets (SESSION_SECRET and DATA_ENCRYPTION_KEY), pulls the latest image, and restarts the container with the same configuration.
You'll see:
Existing installation detected — reusing secrets
Pulling latest Slipway image...
Starting Slipway dashboard...
========================================================
Slipway updated successfully!
========================================================Version Checking Configuration
Update notifications are configured in config/slipway.js:
module.exports.slipway = {
// Show update banner in dashboard (default: true)
showUpdateNotifications: true,
// How often to check (default: 1 hour)
updateCheckInterval: 60 * 60 * 1000
}Rollback
If an update causes issues, review schema compatibility and restore planning before choosing an older image. Download the installer for the reviewed release and pass an explicit version:
curl -fsSL https://raw.githubusercontent.com/sailscastshq/slipway/v0.0.86/install.sh -o install-slipway.sh
bash install-slipway.sh 0.0.86Use the release appropriate to your recovery plan. Pulling an old image alone does not make the installer choose it. An application image downgrade does not undo database schema changes; retain the pre-update backup and keys.
Alternatively, check the container logs to diagnose the issue:
docker logs slipwayThe --restart unless-stopped policy means Docker will keep retrying if the container crashes on startup.
Troubleshooting
Update Check Shows "Unable to Check"
- Network: Ensure your server can reach
api.github.comover HTTPS - Rate limiting: GitHub allows 60 requests/hour for unauthenticated requests. Slipway caches results for 1 hour to stay within limits
Dashboard Update Fails
If the one-click update fails:
- Check the browser console for error details
- Fall back to the manual update method
- If the dashboard is unreachable, SSH into your server and check
docker logs slipway
Container Won't Start After Update
- Check logs:
docker logs slipway - Verify volumes exist:
docker volume ls | grep slipway - Check the release notes for breaking changes or new required environment variables