Weave Code
Spin Laravel Package
serversideup/spin
Spin is a Docker-based local development environment for Laravel that gets projects running quickly with preconfigured PHP, database, and caching services, so you can develop without installing PHP, Composer, or Node locally.
🚀 Replicate your production environment locally using Docker. Just run "spin up". It's really that easy.
Frequently asked questions about Spin
- What is serversideup/spin and how does it work with a Laravel app?
- Spin is a Docker-based local development environment for Laravel, distributed as a thin Bash CLI (bin/spin plus one script per command under lib/actions) that wraps docker compose. Running spin up starts a production-shaped stack defined by docker-compose.yml plus an environment overlay, with preconfigured PHP, database, and cache services. It is deliberately a developer-experience layer: it never enters your application's dependency graph or request lifecycle, and its goal is environmental parity rather than application logic. Because the abstraction is shallow and arguments pass straight through to the underlying Compose subcommand, there is very little magic and very little lock-in.
- How do I install Spin and do I need PHP, Composer, or Node installed locally?
- Installation is a single shell script that puts a global spin binary on your machine, and the only hard requirement is Docker. You do not need PHP, Composer, or Node on the host, because the containers Spin runs act as the execution vehicle for the PHP tooling, Node, and other CLI utilities. Nothing is added to composer.json or composer.lock, and there is nothing to build into your deployable artifact.
- Does Spin add a Composer dependency to my Laravel project?
- No. Spin ships no PHP library surface and no Composer package, so it never appears in your dependency graph, autoloader, or framework bootstrapping. Your composer.json, composer.lock, and production artifact stay untouched, which makes adoption and reversal both cheap. The tradeoff is that Composer tooling such as composer update still runs inside Spin's PHP container rather than on your host.
- Which PHP and Laravel versions does Spin support?
- Spin does not pin PHP or Laravel versions itself; the PHP version is whatever image you reference in your docker-compose.yml, so you choose and upgrade it like any other Compose service. That means current and older Laravel releases work as long as your container image satisfies their platform requirements. The real constraints are environmental: Docker must be available, and Spin keeps Bash 3.2 compatibility, so any wrapper scripts you write should avoid associative arrays and mapfile.
- How does Spin compare to Laravel Sail, DDEV, Lando, or plain Docker Compose?
- Spin is the shallowest of the options: a Bash pass-through to docker compose with Laravel-friendly defaults and an environment overlay, which makes it easy to read, debug, and walk away from. Sail is Laravel-official and tightly integrated with artisan, while DDEV and Lando offer richer, more opinionated tooling and broader service catalogs. If your team is already fluent in raw Compose or standardized on one of those tools, Spin adds little beyond convenience, so treat it as a cheap default rather than a migration target.
- Does Spin work on Windows, Colima, or Rancher Desktop?
- macOS, Linux, and WSL2 are the supported surfaces, while native Windows shells are not supported, so Windows developers should run inside WSL2. Docker Desktop is the documented path, and alternative runtimes such as Colima or Rancher Desktop are not confirmed by the project, so validate them with a short spike before standardizing. Agree up front who owns diagnosing Docker-level failures, because that layer sits outside Spin's responsibility.
- How do I pin the Spin version so every developer gets the same environment?
- Spin installs as a global binary with a self-upgrade path and a cached update check, so per-repository reproducibility is not guaranteed by the tool alone. Document a minimum Spin version in onboarding, add a preflight version check to a Makefile target or setup script, and reuse that check in CI smoke jobs. Before rollout, also audit existing .env files for COMPOSE_FILE, SPIN_ENV, and COMPOSE_CMD, because Spin's defaults can silently win over values your team set by hand.
- What license is Spin under, and can we bundle it into an internal developer image?
- Spin is GPL-3.0, which is normally unproblematic when you simply invoke the CLI as part of a local development workflow. Redistribution is a separate question: bundling the binary into a shared internal dev image or a distributed developer toolkit is a copyleft conversation, so route that decision to legal before shipping anything. Keep the plain developer-machine install as the default path.
- Can we use Spin in CI or for provisioning and deploying to servers?
- Spin's core value is up, down, exec, logs, build, and run against a local Compose stack, and that is the scope recommended for an initial rollout. The spin provision and spin deploy commands touch servers and Docker Swarm, which is a different risk class and belongs in a separate ops review with its own approvals. Many teams also keep CI on raw docker compose so pipelines do not depend on a developer-machine CLI.
- Is Spin actively maintained, and should we fork or extend it?
- It is a single-vendor open source project from serversideup with roughly 1.5k stars and a mature, low-differentiation feature set, which is good for stability but weak for influencing the roadmap. Because the codebase deliberately keeps Bash 3.2 compatibility, upstream contributions and local forks move slower than a typical PHP library, so plan to adopt and constrain rather than invest in extending it. Any wrapper you add should preserve that Bash 3.2 constraint.
Weaver
How can I help you explore Laravel packages today?