Porter Laravel Package

Product Decisions This Supports

• Developer onboarding and environment parity. Porter standardizes how background services (queue workers, Horizon, websockets/Reverb, Vite, Mailpit, third-party Docker containers) are declared and launched. This reduces README sprawl and "open six terminals and remember these commands" tribal knowledge.
• Local DevEx roadmap. Informs the build-vs-adopt decision between a first-party, config-driven process manifest (a porter.php-style contract) and existing options like Docker Compose, Laravel Sail, or Procfile-based runners.
• Build vs. buy/borrow. Adopting Porter instead of building an internal process runner saves engineering weeks. It is a dev-only dependency with a small blast radius, making it a low-commitment, reversible bet.
• Standardization across repositories. A version-controlled service manifest makes it easier to template new Laravel projects and keep team members' machines aligned, which supports platform-engineering and internal-tooling initiatives.
• Support-cost reduction. Fewer environment-specific setup tickets and faster time-to-first-PR for new hires; evaluate against DevEx metrics (onboarding time, setup failure rate, setup-related support tickets) rather than customer or revenue KPIs.
• Explicit non-goal. This is an internal productivity lever, not a customer-facing capability. It should not be prioritized against product roadmap items on the same scale.

When to Consider This Package

Consider adoption when:

• Your team is Laravel/PHP-centric and already lives in artisan/Composer workflows.
• You routinely need several long-running local processes at once (queue workers, Horizon, websockets, Vite, Mailpit, local Docker services) and want a single start/stop command.
• You want a declarative, committed manifest instead of ad-hoc shell scripts or per-developer aliases.
• You value convention over configuration and are comfortable with an opinionated, small-surface tool.
• You can install it as a require-dev dependency and treat it as replaceable tooling.

Look elsewhere when:

• You need production process supervision — use Supervisor, systemd, or your orchestrator. Porter is a development tool.
• You need polyglot/cross-language orchestration — Foreman/Procfile, Overmind, or Honcho are more established.
• You need fully reproducible, containerized environments — Docker Compose, Laravel Sail, or Devcontainers are stronger fits.
• Maintenance risk is unacceptable. With a 2023 last release and a small maintainer footprint, you must be willing to pin the version, fork, or replace it.
• You require Windows parity, enterprise support/SLAs, or granular security controls around arbitrary command execution.
• Your process list is trivial — composer run dev scripts or a Makefile are enough; avoid tooling for its own sake.

How to Pitch It (Stakeholders)

Executive summary. Porter is a small, dev-only Laravel package that lets a team declare background services in a config file and start/stop them with one command. It is not a product feature and carries no customer-facing risk; the cost is a dev dependency plus a light team convention. The upside is faster onboarding, fewer "works on my machine" setup failures, and less README drift.

Recommendation. Timebox a one-sprint spike on one or two repositories, measure onboarding time and setup-related support tickets before and after, and only standardize if the maintenance posture (single 2023 release, modest community) is acceptable alongside version pinning and a documented exit plan.

For engineering. It fits Laravel conventions, keeps process definitions in version control, and is easily swapped for Compose/Sail or a Procfile runner if the project stalls. Treat it as a reversible, low-commitment investment in developer experience rather than a long-term platform dependency.