Syrup Laravel Package

Technical Evaluation

What the asset actually is. keboola/syrup is not a Laravel package in any conventional sense — no service provider, no facade, no config publishing, no Eloquent surface. It is a PHP CLI/library layer that wraps Docker to build and execute Keboola Connection components. It sits in the Symfony Console / standalone-library family, which means the "Laravel fit" question is mostly the wrong question: you would consume it as an out-of-process tool, not as an in-process framework dependency.

Architecture fit. Poor-to-moderate for an in-app integration and moderate-to-good only as a sidecar/CLI invocation. The package's core value is a component-spec-aware wrapper around docker run — image resolution, config/manifest handling, environment injection, output capture. Any Laravel application that already speaks HTTP to a job runner gains little from embedding this; an application that specifically needs to execute Keboola component images on its own Docker host gains a reference implementation of the contract, which is the more durable asset than the code itself.

Integration feasibility. Mechanically easy (composer require, then shell out via Symfony\Process or a queued job), politically and operationally hard. The real cost is not wiring — it is accepting ownership of an unmaintained Docker-orchestration layer that must track the component spec, Docker API behavior, and PHP/Symfony version drift.

Technical risk — this is the dominant finding. Zero stars, zero dependents, and a composite score of 0 are not "early-stage" signals; they are "effectively abandoned or never public-facing" signals. Concretely:

• No community surface. No issue triage, no security disclosure path, no downstream users to absorb breakage. Every defect is yours.
• Transitive dependency decay. A Symfony Console-era codebase will pin versions that collide with current Laravel/Symfony majors; resolution failures are likely before functional failures.
• Privileged runtime surface. Executing arbitrary component images implies access to a Docker socket. In a Laravel deployment that is a container-escape-adjacent capability; it needs a dedicated host or a broker, not the app container.
• Spec drift. Keboola's component manifest/runner conventions have moved on (job-runner, docker-runner lineage). Syrup likely encodes an older contract.

Key questions for the spike.

1. Is there a maintained successor inside the Keboola org, and does Syrup still appear in any shipped product path?
2. What license and what PHP/Symfony constraint set does composer.json declare, and does it resolve against our current lockfile?
3. Does it require direct Docker socket access, or can it target a remote/rootless daemon?
4. Is the component execution contract (manifest, config, expected output files) documented independently of this code — i.e., can we reimplement rather than adopt?
5. Who inside our org would own this in 12 months?

Integration Approach

Stack fit. Treat Syrup as a reference implementation and CLI, not a library. Laravel should own orchestration: a queued job dispatches to a small internal service (or a short-lived container) that invokes Syrup or a successor binary, streams logs to object storage, and returns a structured result. Keep the Docker boundary outside the PHP-FPM process entirely.

Migration path (if adopted).

1. Spike fork — vendor the repository under our namespace, pin all dependencies, and get a single component image running end-to-end in a sandbox. Timebox this hard; if it does not resolve in two days, the answer is "reimplement."
2. Contract extraction — document the exact manifest fields, env vars, input/output file conventions, and exit-code semantics Syrup relies on. This document, not the code, is what survives.
3. Adapter interface — define an internal ComponentRunner port (run(componentRef, config): Result) with a Syrup-backed adapter and a stub for a future native runner.
4. Isolate — run it in a dedicated worker container with Docker access, no shared secrets, strict CPU/memory/time limits.
5. Decommission path — once the contract doc exists, a native docker run implementation with symfony/process is roughly a few hundred lines and removes the dependency permanently.

Compatibility. Expect friction on PHP minor versions and Symfony majors; expect Docker API version negotiation issues on newer daemons. Validate against our exact base image and daemon version, not "latest."

Sequencing. Contract documentation → spike → adapter → operational hardening → replacement decision. Do not let the spike become the plan.

Operational Impact

Maintenance. Total. An unmaintained package with no dependents means no upstream fixes, no CVE patches, and no upgrade guides. Budget for a named owner and a recurring quarterly review against PHP, Symfony, and Docker releases. The realistic 18-month outcome is a fork that diverges from upstream and must eventually be rewritten.

Support. None externally. Internal runbooks must cover image pull failures, daemon restarts, and spec mismatches, because there is no community to escalate to.

Scaling. Bounded by the Docker host, not by PHP. Throughput is a function of concurrent container slots, image pull latency, and registry bandwidth. There is no scheduling, queueing, or back-pressure in this layer — Laravel's queue becomes the throttle, and cold-start image pulls are the dominant tail-latency source. Plan for a local registry mirror.

Failure modes to instrument explicitly.

• Docker daemon unreachable or API version mismatch → hard failure, no retry semantics in-package.
• Image pull timeout / registry auth expiry → silent-looking hangs in the parent job.
• Container OOM or non-zero exit without structured output → indistinguishable from a component bug; capture stdout/stderr and exit code separately.
• Orphaned containers after worker death → disk and socket exhaustion; needs a reaper.
• Secrets passed as env vars → visible in docker inspect; use file-based or secret-store injection.
• Log volume on verbose components → unbounded growth in the app's storage layer.

Ramp-up. High and specialized. A new engineer needs the Keboola component model, Docker operational basics, and the internal adapter — realistically one to two weeks before they can safely debug a failed run. That cost recurs with every team member who touches it, which is the strongest argument for keeping the surface small and the contract documented.

Recommendation. Do not adopt keboola/syrup as a production dependency on the strength of the package itself. Use it as a one-time reference to define the component-execution contract, build a thin internal runner behind a stable interface, and treat the repository as documentation with an expiration date.