Api Laravel Package

Product Decisions This Supports

• Build vs. buy for server lifecycle management. This package turns Cipi from "a thing ops SSHs into" into an API surface you can build product on. If your roadmap includes any self-serve infrastructure control (spin up apps, change deploy config, rotate settings) the question shifts from "do we build a control plane?" to "do we build a UI on top of this API?" — a materially cheaper decision.
• Config-as-code / GitOps roadmap. The headline of 1.35.0 is that cipi.yml — the app's server configuration — is now inspectable (GET /apps/{name}/yml), appliable (POST /apps/{name}/yml/apply), and continuously reconciled from Git (auto enable/disable). That is the enabling primitive for a "commit to change infrastructure" workflow. Decide deliberately whether that is a v1 feature or a v3 one; the capability now exists either way.
• Feature scoping for an internal admin panel. Six terminal outcomes for apply (applied, unchanged, partial, blocked, invalid, no-file) is a UX requirement, not an implementation detail. Budget design time for blocked/invalid states — they are the ones users will hit — or scope apply out of the first release and ship read-only plan first.
• Security and governance posture. Auto-apply means write access to the repository equals control of the app's server configuration. That is a real trust-boundary decision to make explicitly with security, not a checkbox. It also justifies the new split between yml-view (read) and yml-manage (write) abilities — mirror that split in your own roles rather than handing out yml-manage broadly.
• AI/agent strategy. The MCP server now exposes 76 tools including AppYmlShow, AppYmlApply, and AppYmlAuto. If you are evaluating agent-driven ops, this release moves the package from "plausible" to "demoable this quarter." If you are not, it costs you nothing.
• Upgrade sequencing. Support for servers below Cipi 5.6.4 returns 503 on the new routes only; everything else is unchanged, and existing API tokens silently lack the new abilities. That is a clean, non-breaking upgrade path — a point in favour of adopting now rather than waiting.

When to Consider This Package

Adopt when:

• You are already running Cipi on the target servers and are on (or can move to) CLI ≥ 5.6.4 — below that, the entire cipi.yml feature set is a 503.
• You want the server-management surface available to something other than a human with SSH: an admin panel, a deploy pipeline, a chat/agent interface, or a customer-facing dashboard.
• You are comfortable issuing new API tokens with yml-view / yml-manage. Existing tokens deliberately do not inherit them — plan the token rotation as part of rollout, not after.
• Your team has, or wants, a GitOps muscle: someone must own reviewing cipi.yml changes in PRs before auto-apply is switched on.
• You need read-only visibility before write access. GET /yml is synchronous and read-only, which makes it a low-risk first integration and a good pilot for stakeholder buy-in.

Look elsewhere when:

• You are not on Cipi. This is a control surface for one specific server stack, not a general provisioning layer.
• You need Kubernetes, multi-cloud abstraction, or container orchestration — Cipi's model is single-server app hosting.
• Compliance forbids configuration changes originating from a Git webhook without a human gate. Auto-apply is optional, but the feature's centre of gravity assumes you will eventually want it.
• You need per-field or per-environment permission granularity within cipi.yml. The ability model is coarse: view, or manage the whole file.
• You are unprepared to handle mid-flight job failure. partial and blocked outcomes terminate the job as failed while still carrying a result payload — clients that treat failed as "nothing happened" will misreport server state.

How to Pitch It (Stakeholders)

To executives: This release lets us manage app server configuration through an API and through Git, instead of by hand over SSH. The practical payoff is fewer manual ops steps, an auditable record of who changed what, and the option to expose controlled self-service later without building a control plane from scratch. It is additive and non-breaking: older servers keep working, existing integrations are untouched, and the new capability is gated behind explicit new permissions we choose to grant. The main judgement call it forces is governance, not engineering — enabling auto-apply means repository commit rights become server-config rights, so that switch stays off until we have review rules in place.

To engineering: Version 1.35.0 adds three cipi.yml endpoints — a synchronous read-only plan (yml-view), an async app-yml-apply job, and idempotent auto-apply toggles (yml-manage) — plus matching MCP tools, CLI whitelist entries, and OpenAPI schemas. It hard-depends on Cipi CLI 5.6.4 for these routes only; everything from 1.34.0 behaves identically, and older servers answer 503 on the new paths rather than failing loudly elsewhere. Existing tokens do not receive the new abilities by design, so token issuance is a rollout step. Note the apply job's result contract: blocked, invalid, partial, and no-file all end as failed but still return a structured result — handle the payload, not just the status. Two smaller changes land alongside: job results now backfill a missing app key from job parameters, and the MCP server is at 1.5.0 with 76 tools on a single tools/list page.