v1.2.2

LaraShip 1.2.2 synchronizes release metadata, adds optional Docker Hub publication and fixes the PHP address-change E2E fixture.

Fixed

• Set VERSION, release notes and installation/publication examples to 1.2.2. The v1.2.1 publication attempt was blocked because its source still declared VERSION=1.2.0; tag/version and exact-commit CI checks remain enforced.
• Use dynamic Docker IPAM allocation instead of a static --ip in the PHP address-change E2E fixture. Retry once if PHP reuses its old address, and restore PHP plus Nginx routing on every exit to prevent cascading test failures.

v1.2.1

v1.2.1

v1.2.0

LaraShip v1.2.0

LaraShip 1.2.0 strengthens deployment endpoint security, delivers smaller PHP runtime images and makes GitHub release publication safe to retry.

Security

• Deployment endpoints now require HTTPS by default. HTTP requires --allow-insecure-endpoint or ALLOW_INSECURE_ENDPOINT=true in the deployment configuration.
• Endpoint URLs and JSON payloads stay off the curl command line. Endpoint logs discard response bodies and raw diagnostics that could expose credentials.
• Endpoint requests disable redirects and user curl configuration while preserving TLS certificate verification.

PHP runtime images

• Pin PHP 8.3.35 and 8.2.34, Composer 2.10.3, PECL Redis 6.3.0 and APCu 5.1.28.
• Pin base image digests and verify PECL source checksums.
• Separate compilation from runtime, removing compilers, development headers, debugging tools and optional service packages.
• Reduce the Compose PHP 8.3 image by approximately 83%: 401 MB versus 2.36 GB for the previous recipe rebuilt with matching versions, measured as uncompressed local image size.
• Preserve non-root execution and add FPM liveness checks, a 10-second FPM process-control timeout and a 15-second Compose stop grace.

Fixes

• Refresh Nginx FastCGI resolution after PHP container recreation, preventing stale upstream addresses from causing HTTP 502 responses.
• Make release publication retryable: verify existing assets, upload missing files and reject conflicting content without overwriting published assets or release notes.
• Serialize publication per tag and support manual recovery while retaining the exact-commit CI gate.

Upgrade notes

• Existing HTTP endpoint integrations must adopt HTTPS or explicitly enable HTTP.
• The unsupported PHP 8.1 template has been removed. PHP 8.3 remains the default; PHP 8.2 remains available for compatible Laravel 12 applications.
• To upgrade existing PHP images, copy the complete laravel/.docker/php/ directory, including helper scripts and .dockerignore, apply the relevant Compose health and shutdown settings, and rebuild the affected PHP roles.
• Applications requiring removed optional binaries or fonts need a custom image. Existing deployments and database volumes are not upgraded automatically.

Validation

• Release preparation passed 184 Bats checks and 54 Python tests without skips, plus ShellCheck, Bash syntax, actionlint and release metadata checks.
• Both PHP variants previously passed real PostgreSQL/MySQL access, Laravel installation and migrations, non-root/read-only execution and active-request draining checks.
• Full installer/Kubernetes E2E and ARM builds were not repeated for this release preparation. Publication requires successful remote CI for the final tagged commit.

v1.1.1

LaraShip v1.1.1

This patch fixes Kubernetes CI fixture permissions and restores consistent release metadata.

Fixed

• Fixed Kubernetes E2E failures on non-root GitHub Actions runners. Composer now uses the invoking user’s UID/GID and a writable temporary home, allowing Laravel route edits and complete cleanup.
• Restored the missing 1.1.0 changelog section that broke version-consistency and release-note extraction checks.
• Updated VERSION, the README installation example and release metadata to 1.1.1.

Tests and documentation

• Local Kubernetes E2E now runs as a non-root operator, covering the permissions regression previously missed by root-operated tests.
• Updated Docker and Kubernetes operation guides and synchronized verified project context and navigation.

Validation

• Full local Docker unit run: 180 Bats checks, 23 Python tests and ShellCheck passed.
• Real Laravel 12 and 13 passed Kubernetes E2E on kind, including migrations, replicas, workers, HTTP, read-only runtime, graceful shutdown, dependency outage, Pod replacement and cleanup.
• Release preparation passed three metadata/version checks and five release-gate tests. Notes for 1.1.1 and 1.1.0 extract independently.

Upgrade notes

No database migration or application redeployment is required for this patch. Native Bash, Docker CLI and Kubernetes deployment contracts remain compatible with 1.1.0.

Publication requires successful CI for the exact tagged commit.

v1.1.0

LaraShip v1.1.0

LaraShip now offers a Docker CLI distribution and an independent Kubernetes deployment backend alongside the native Bash toolkit. Existing Bash and Docker Compose workflows remain supported.

Docker CLI

• Added a buildable CLI image containing LaraShip scripts, templates and dependencies.
• Supported commands include deployment, updates, backups, activation, deactivation, removal and project listing.
• Added preflight checks for the Linux host's Docker socket, networking, project directories, shared locks and archive paths.
• Preserved interoperability between native Bash and container operations.
• Added configurable private ZIP output through LARASHIP_ARCHIVE_DIR, retaining /tmp as the native Bash default.
• Updated container project listings to inspect certificate volumes through the Docker daemon.

Kubernetes deployment

• Added kubernetes render and kubernetes deploy for existing Laravel applications packaged into immutable images.
• Added a multi-stage application image template with PHP, production dependencies, Redis support and graceful shutdown.
• Generated web and queue worker Deployments, a ClusterIP Service and a dedicated migration Job.
• Required an explicit cluster context and immutable, versioned ConfigMap and Secret references.
• Completed migrations before applying application workloads; repeated deployments reuse the matching migration Job.
• Validated reused Job ownership, runtime settings and execution policy.
• Serialized deployments with a cluster Lease, retaining the lock when migration or rollout completion cannot be confirmed.
• Supported non-root execution, a read-only root filesystem, separate startup/readiness/liveness probes and external application state.
• Reconciled disabled workers to zero replicas.

Testing and documentation

• Added the kubernetes.yml GitHub Actions workflow and Kubernetes README badge.
• Extended the release gate to require successful Kubernetes checks for the exact release commit.
• Added Docker/Kubernetes operation guides and an architecture decision record.
• Passed 180 Bash checks, 23 Python tests, syntax checks, ShellCheck, actionlint and independent review.
• Verified actual CLI/native lifecycle operations with PostgreSQL and MySQL.
• Verified Laravel 12 and 13 on disposable Kubernetes 1.37.0, including migration reuse, two web replicas, worker disabling, HTTP access, Pod replacement and graceful completion of an active request during shutdown.

Compatibility and scope

The Compose CLI runner targets Linux servers with an existing Docker Engine. Native database provisioning and deletion remain native Bash operations. The CLI image is buildable from source; registry publication is separate.

Kubernetes requires a prepared application image and external database and persistent services. Existing Compose projects and database volumes are not converted automatically. Cluster backups, scheduling and Ingress/TLS remain operator-managed. Database and workload rollback are not automatic.

Local Kubernetes verification used a single-node cluster with PostgreSQL. Multi-node operation, production sizing and real external Redis, object storage and Ingress/TLS require additional validation.

v1.0.0

LaraShip v1.0.0

LaraShip provides a native Bash toolkit for deploying and managing Laravel applications on Ubuntu. Applications run in Docker Compose, with a shared Nginx reverse proxy and optional Let's Encrypt certificates.

Features

• Deploy a fresh Laravel application or an existing Git repository, with branch selection, SSH deploy keys and post-deployment commands.
• Support Laravel 12 and 13 on PHP 8.3, with Laravel 13 as the default.
• Use official PostgreSQL 17 and MySQL 8.4 LTS images, or connect to native databases on the server.
• Enable optional Filament 5, Redis, queue worker, Horizon and database backup modules.
• Configure deployments through command-line options, configuration files and reusable admin-panel, api and staging presets.
• Preview effective settings with --dry-run, without changing the server or exposing credentials.
• Manage projects with deployment, update, activation, deactivation, removal and listing utilities.
• Support HTTP deployments with --no-ssl, HTTPS certificates and optional HTTP Basic Auth.

Security and reliability

• Production defaults: APP_ENV=production, debugging disabled, PHP without Xdebug and project ports bound to loopback.
• Environment files and backup archives use private permissions.
• Existing project paths are protected against accidental replacement; the shared proxy name is reserved.
• Database credentials are encoded safely, with validation for unsupported characters in the official MySQL initializer.
• Project and proxy locks prevent conflicting operations. Proxy changes are validated before application, with rollback on failure.
• Git updates enable maintenance mode before changing application code. Failed updates retain maintenance mode and provide recovery guidance.
• Initial migration failures abort deployment. Authenticated database and HTTP checks verify readiness before reporting success.

Backups and restoration

• Scheduled and manual database dumps, configurable retention, backup listing and restoration.
• Native PostgreSQL backup clients automatically match the server's major version, including PostgreSQL 16.
• Restore input is validated before maintenance or service shutdown.
• Project ZIP archives use private staging and are published without overwriting existing files.

Validation

Local verification covered 42 isolated Docker scenarios, including PostgreSQL/MySQL deployments, Git updates, modules, proxy operations and backup/restore. Additional checks verified native PostgreSQL 16 backup compatibility. Bash syntax, ShellCheck and automated regression tests passed.

Existing installations

Updating the toolkit does not rewrite previously generated project configurations or upgrade database volumes. Apply template changes explicitly. Moving from Elestio images to official database images requires a logical dump and restoration into a separate empty volume, retaining the original database for recovery.

Database migrations are not rolled back automatically. Review migration compatibility and preserve backups before updating an existing application.