Sdk Laravel Laravel Package

Product Decisions This Supports

• Feature: customer-managed network allowlisting for external database writers. v0.9.1 adds an optional ExternalDatabaseWriterNetworkAccess contract for reading and replacing a writer’s allowed public IPv4 addresses. This supports self-serve or support-assisted management of database access without custom tooling.
• Security and compliance roadmap. The ability to replace the allowlist, including revoking all access with an empty list, supports least-privilege access reviews, incident response, and customer-controlled egress controls.
• Build vs. buy. The package provides a revision-checked contract and policy/application status semantics. That reduces the need to design custom concurrency handling and access-policy reconciliation for this narrow capability.
• Operational workflows. Teams can expose “saved policy” versus “applied policy” states, which is important for product UX and support: customers need to know whether a network change is merely recorded or actually enforced.
• Use cases: external database writers, partner integrations, regulated environments requiring IP allowlisting, and customer-admin network settings.
• Roadmap dependency, not a standalone launch. Adoption requires paired Core and isolated-runtime implementations. Product plans should treat this as an ecosystem capability with prerequisite delivery, not as an independently shippable feature.

When to Consider This Package

Consider adoption when:

• You already depend on this Laravel/PHP package or its surrounding SDK ecosystem.
• You need programmatic management of public IPv4 allowlists for external database writers.
• You need revision-checked updates to avoid lost updates when multiple admins or systems change network policy.
• You want explicit revocation behavior via an empty list.
• You can surface both saved and applied network policy states in admin/support workflows.
• Your paired Core and isolated-runtime implementations are available and verified.

Look elsewhere or defer when:

• You need IPv6, CIDR ranges, private network controls, or broader firewall/DNS capabilities; v0.9.1 describes public IPv4 addresses.
• You need a standalone package; this release requires paired Core and isolated-runtime implementations.
• You cannot distinguish browser IP from the database client’s egress IP in your UX; the release note explicitly warns these may differ.
• You require stable 1.0 API guarantees; this is still a pre-1.0 release.
• Your need is infrastructure-level enforcement rather than an application/SDK contract. This package exposes policy management, but enforcement depends on the runtime implementation.

How to Pitch It (Stakeholders)

For executives: v0.9.1 adds an optional, low-migration capability for controlling which public IPs may reach external database writers. It supports security and compliance use cases, reduces manual access-management effort, and enables safer customer self-service. It is not a standalone launch: delivery depends on paired Core and isolated-runtime work.

For engineering: The change is additive and optional. Existing writer provisioning remains unchanged. The contract uses revision-checked updates, supports revocation through an empty list, and returns saved versus applied policy status. Integrate only after the paired implementations are available, and design UI/support flows around the fact that the browser IP may differ from the database client’s egress IP.

For product and support: Prioritize clear status messaging: “saved” is not the same as “applied.” Roll out behind a flag or limited availability until runtime support is proven. Use this to support customer-admin network settings without inventing a custom concurrency model.