- How do I install konekt/gears in a Laravel application?
- Install it with Composer using composer require konekt/gears, then publish the package config and migrations with the vendor:publish command described in the README. Run the migrations to create the settings tables, and attach any traits the package expects to models such as User. Because it is a standard Laravel service-provider package, no manual bootstrapping is normally required beyond the published config.
- Does konekt/gears support per-user preferences and feature flags per model?
- Yes. Gears can toggle features globally or per model, and the package is designed to attach preferences to Eloquent models such as User through traits. That covers the common per-user preference use case and per-entity flags. Tenant-scoped or multi-tenant settings are not clearly documented, so confirm that against the source before relying on it.
- Which Laravel and PHP versions does konekt/gears support?
- The package declares its Laravel and PHP constraints in composer.json, and those constraints are the authoritative compatibility matrix. Verify them against your pinned versions before spiking, since low-adoption packages often lag on newer PHP releases. Check specifically for PHP 8.2 and 8.3 dynamic-property and deprecation warnings.
- Can I define gears in code instead of the database?
- Gears can be defined in code or in the database. A config-declared schema is the typical pattern: you describe settings and their types and defaults in configuration, while values are persisted through Eloquent. Defining in code gives you version-controlled defaults, while database-defined gears let admins add or change toggles without a redeploy.
- How does time-based activation of a gear work?
- Konekt Gears supports scheduling time-based activation, so a feature can switch on automatically at a defined moment rather than requiring a manual toggle or redeploy. The exact scheduling API and how the package evaluates activation windows should be confirmed in the README and source. Treat it as an application-layer convenience and test boundary conditions in your own environment.
- What Blade directives, middleware, and Eloquent scopes does konekt/gears provide?
- The package provides Blade directives for gating UI, middleware for gating routes, and Eloquent scopes for querying models by gear state. Together they let you gate features without redeploying, using the same underlying flag evaluation. Review the README for exact directive and middleware names, since these are the API surface you will depend on.
- Is konekt/gears a good alternative to spatie/laravel-settings?
- It is comparable in scope but far less adopted: six stars and zero dependents versus spatie's much larger user base. Gears brings a preferences abstraction and schema conventions, but if you only need a simple key-value settings table, about 150 lines of your own code carries less long-term risk. Benchmark both against a hand-rolled table before committing.
- Can konekt/gears store encrypted or sensitive settings?
- Encrypted or sensitive-setting support is not documented in the provided material, so assume you must layer encryption yourself if you need it. Because settings are database-backed, they are not suitable for secrets required before the database is available, such as DB credentials or queue driver selection. Keep those in environment configuration and use Gears for application-layer settings.
- How does caching and cache invalidation work when settings change?
- Settings are persisted with Eloquent, so reads can be cached and writes need invalidation; the assessment flags the cache invalidation strategy and its configurability as open questions. Verify whether cache store, TTL, and tag support are configurable in the published config. For production, add a thin internal adapter so you control caching and invalidation without touching domain code.
- Is konekt/gears actively maintained and safe to use in production?
- The dominant risk is adoption and longevity, not code quality: a single maintainer, no dependents, and no reported production usage mean real abandonment risk within 12 to 24 months. The MIT license lets you fork or vendor it, and the surface area of facade, traits, config schema, and a few migrations is small enough for a mid-level Laravel engineer to own. Frame the decision as adopting a small codebase you may need to maintain.