- What is lara-zeus/bolt used for?
- Bolt is a form builder for Laravel that stores form schemas and field definitions in the database, then renders them anywhere in your app with a Blade component. You get built-in validation, common field types, and persisted submissions for review in your admin panel. It fits teams already using the Lara Zeus and Filament ecosystem.
- How do I install lara-zeus/bolt?
- Install it with Composer using composer require lara-zeus/bolt, then publish and run the migrations so the forms, fields, and submissions tables exist. Publish the config and views if the package exposes them, and register the Filament plugin on the correct panel. Review the source and migrations rather than relying on the README alone, since the docs are thin.
- Does Bolt require Filament and Livewire?
- Yes. Bolt sits on the Filament and Livewire stack, so adopting it in a non-Filament Laravel app effectively means adopting that platform too. That is a real platform decision, not a side effect of a single custom-forms request. If your app is already a Laravel plus Filament shop, Bolt is a bounded addition to an existing mental model.
- Which Laravel, PHP, and Filament versions does Bolt support?
- The supported versions are defined in the package composer.json and the Filament plugin registration, so check those before committing. Release metadata for Bolt has been unreliable in the past, so verify against Git tags and recent commit cadence on GitHub. The tightest coupling is the supported Filament major, because a form builder touches routing, auth, storage, and the admin panel.
- How do I render a Bolt form in my Blade views?
- Bolt provides simple Blade components, so you render a form by referencing the stored form definition in a view rather than hardcoding fields. The component handles field rendering, layout, and validation for you. Confirm the exact component name and parameter signature in the package source for your installed version.
- Do I have to hardcode form fields in code?
- No. Bolt is database-driven, so forms and fields are defined and managed at runtime, and non-developers can add or reorder fields through the admin interface without touching code. That keeps field definitions, validation, and layout in sync. You can also define forms in code if you prefer a fluent definition.
- How are Bolt form submissions stored?
- Submissions are persisted in the database for later review in your admin panel. What the context does not specify is whether each submission is stored as normalized rows per field or as a JSON blob per entry, which matters for reporting, per-field deletion, and GDPR erasure. Answer that by reading the migrations and submission model in source during a short spike, because it is hard to reverse later.
- Can I create custom field types in Bolt?
- Yes, Bolt is extensible through a field base class, which is your extension point for custom field types. Before building on it, confirm the base class contract and how custom types are registered in the Filament panel. That is one of the three things a one-to-two-day source-reading spike should settle.
- Is lara-zeus/bolt safe to use in production?
- Bolt is MIT-licensed and self-hosted, so respondent data stays in your database and there are no per-seat or per-submission fees. The bigger production concern is supply chain: with around 243 stars, zero public dependents, and a single maintainer, plan for best-effort maintenance with no SLA. Watch the supported Filament major closely, and add your own hardening for public endpoints and file uploads.
- Does Bolt support multi-tenancy and per-tenant forms?
- The package documentation does not state that forms, fields, or submissions are scoped per tenant out of the box. If you are multi-tenant, assume scoping is yours to build unless you verify otherwise in source. Tenant leakage is a real risk if you rely on the package for isolation without checking.