Syrup Laravel Package

Product Decisions This Supports

• Build vs. buy on a "bring your own code" execution layer. Syrup is Keboola's runner for executing packaged components (Docker-image-based scripts) inside a controlled environment — it defines the contract around config injection, input/output directory mapping, and environment variables. That contract is the reusable part; the code is the reference.
• Roadmap: do we support third-party / customer-authored components? If a roadmap item is "let customers ship their own extractor, transformation, or writer," Syrup is a concrete prior-art example of how a data platform solved it, including the failure modes (credentials handling, sandbox boundaries, contract versioning).
• Feature scoping for sandboxed job execution. Useful as a checklist when specifying our own runner: what gets mounted, what gets passed as config vs. secrets, how errors and exit codes are surfaced, how manifests declare parameters.
• Developer-experience investment. A local emulation of production component execution is a real onboarding cost-saver. Syrup-style runners are what make "works on my machine" achievable for pipeline authors.
• Packaging and monetization decisions. If we expose a component marketplace or a custom-code tier, the runner's constraints (resource limits, network isolation, runtime allowlists) directly determine what we can sell and what we must support.
• Explicitly not supported: using this as a production dependency. Zero stars, zero dependents, no description, no adoption signals. It informs decisions; it does not make them for us.

When to Consider This Package

Consider it when:

• You are building on or interoperating with Keboola Connection, or you need your components to remain compatible with the Keboola component contract.
• You are designing a "user supplies a Docker image, platform supplies config and credentials" model and want a working, battle-tested-in-private example of the plumbing rather than a blank page.
• You need local development parity with a hosted pipeline platform — running the same component contract on a laptop or in CI.
• Your stack is PHP/CLI and you want to read, not depend on, the implementation. Note the framing: this is not meaningfully a Laravel package in the sense of service providers, facades, and framework integration. It is Docker/CLI infrastructure that happens to be written in PHP. Laravel contributes nothing specific here beyond being able to shell out to it.

Look elsewhere when:

• Maintenance and support matter. No stars, no dependents, no description, no visible release cadence. There is no CVE process, no upgrade path, no one to file an issue with. Treat it as archived-by-default.
• You need a supported dependency with documentation and a community. Nothing here clears that bar.
• Your execution target is Kubernetes, serverless, or a managed batch service. Argo Workflows, Nomad, Temporal, AWS Batch, or Cloud Run Jobs will give you isolation, retries, observability, and an operator ecosystem that a single-container runner does not.
• You need multi-tenant isolation guarantees. A Docker-socket-adjacent runner is a hard sell to a security review for untrusted customer code; you likely want gVisor/Firecracker-class isolation or a managed sandbox.
• You are not in the Keboola ecosystem. Without contract compatibility as a goal, you are paying the conceptual overhead of someone else's data model for no benefit.
• Throughput and parallelism are near-term concerns. This is a per-job executor, not an orchestrator; plan the queue and scheduler separately.

How to Pitch It (Stakeholders)

To executives: This is a free reference design for one of our riskier roadmap questions — how to let customers run their own code inside our platform without handing them the keys. It is not a product we should depend on. The adoption signals are as close to zero as they get: no stars, no dependents, no description, no support. The recommendation is a one-to-two day engineering spike: read the source, extract the config/environment/I-O contract, and use it as an input to our own thin runner. The value is avoided design time and avoided mistakes, not code reuse.

To engineering: Pin nothing, vendor nothing, fork nothing. Read it as a specification. What is worth stealing is the shape of the contract — how a component declares its parameters, how input and output are mounted, how secrets are kept out of config, how failures are reported. What is not worth stealing is the implementation: no tests we can trust, no maintenance, no security response. Budget the spike, write a one-page internal design note citing what we kept and what we deliberately changed, and move on.

To security and platform: Flag for awareness that a Docker-based component runner is the pattern under consideration. If we proceed past the spike, the isolation model — not the PHP code — is the decision that needs review, and it should be evaluated against a managed sandbox rather than inherited from this package.

Bottom line: high signal, low trust. Use it to make a build-vs-buy decision; do not let it make the decision for you.