Laravel Optimus Laravel Package

Product Decisions This Supports

• Public identifier strategy (feature-level): Whether to expose sequential database IDs in URLs, invoice numbers, invite links, or API resources, or to obfuscate them. This package is a thin Laravel service-provider wrapper around jenssegers/optimus (Knuth multiplicative-hash based ID encoding) — it makes "short, non-sequential, reversible public IDs" a ~1-day integration rather than a custom build.
• Build vs. buy: The alternative is not "build a hashing algorithm" but "build ID obfuscation plus config, validation rules, route-model binding, and artisan tooling." If your team would otherwise write that glue, this package is the cheap option; the core algorithm dependency still sits with you either way.
• Enumeration / scraping risk mitigation: Relevant whenever predictable IDs leak record counts or permit trivial scraping of /orders/1..N. Treat this as a hardening measure, not an authorization control — every route still needs policy checks.
• Roadmap compatibility signal (this release): 3.13.0 adds Laravel 13 support. That is the material product-relevant change — it means the package will not block a framework upgrade, and it tells you the maintainer is tracking Laravel releases. Docker dev-env tweaks and AGENTS.md are contributor-facing and carry no product weight.
• Upgrade risk (this release): No breaking changes, no deprecations, no API surface changes. Adopting or bumping to 3.13.0 is a low-risk, non-event change from a delivery standpoint.
• Use cases to evaluate against: short links, public "reference numbers" for support tickets and orders, shareable URLs that shouldn't be enumerable, multi-tenant IDs where you don't want to leak volume.

When to Consider This Package

Consider it when:

• You expose integer primary keys publicly and want short, reversible, human-copyable IDs (e.g. ORD-8f3a2b) without a schema migration to UUIDs/ULIDs.
• You need reversibility — you must decode a public ID back to an internal ID for lookups and want that to be a first-class, config-driven operation.
• You're on a currently supported Laravel version; 3.13.0 explicitly covers Laravel 13, and the wrapper tracks the framework's release cadence.
• You want the behaviour centralized behind config and container bindings rather than scattered Optimus::encode() calls in controllers.

Look elsewhere when:

• You need security-grade opacity. This is obfuscation against casual enumeration, not cryptography; a leaked or guessed salt plus known plaintext weakens it. If IDs are a security boundary, use UUIDv7/ULIDs, or signed URLs, or proper authorization.
• You can change the schema. UUID/ULID primary or public keys give you non-enumerability natively, with no salt rotation problem and no decode step. The honest comparison is "one migration" vs. "a dependency."
• You require a stable public API contract. Key rotation, salt management, and any future change to the underlying algorithm will change your public identifier space — plan for a migration path or use unguessable-but-stable identifiers.
• You're on an unsupported Laravel version or need a maintainer with a formal support/SLA commitment. This is a single-maintainer package; that's fine for most apps, not for regulated release engineering.
• The need is narrow and one-off — a single encode helper plus a validation rule is a few dozen lines and may not justify a dependency.

Adoption criteria checklist: pin the version, confirm the salt is treated as a secret and rotated via config, document that obfuscated IDs are not authorization, and add a test asserting decode/encode round-trips and route-model binding behaviour.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost hardening package that stops our public URLs from exposing sequential record numbers — which otherwise reveals how many customers, orders, or tickets we have and makes bulk scraping trivial. It is reversible, so it changes nothing about how our systems work internally. The new release adds support for the latest Laravel version, which means it won't stand in the way of our framework upgrade. Cost is a dependency plus roughly a day of integration; the alternative, a schema migration to UUIDs, is materially more expensive and riskier.

To engineering: cybercog/laravel-optimus 3.13.0 is the Laravel integration layer for Optimus. The update is additive and non-breaking: Laravel 13 support, Docker dev-environment improvements, and an AGENTS.md for AI-assisted contribution — no API changes, no deprecations, no migration required. It gives you config-driven encode/decode, validation rules, and container bindings instead of hand-rolled helpers. Use it to obfuscate public IDs where you want short reversible identifiers; do not treat it as an authorization or encryption boundary, and do not adopt it as a substitute for UUIDs if you're already migrating schemas. Watch the salt as a managed secret, and add round-trip and route-binding tests.

Recommendation: Approve as a routine dependency update / low-risk adoption. No action required beyond pinning the version and confirming Laravel 13 compatibility in our upgrade plan. Revisit only if the salt-management story becomes a compliance concern or the package loses maintenance.