- How do I install ryangjchandler/forge-previewer in a Laravel app?
- You can add it with composer require ryangjchandler/forge-previewer, but treat that as only the first step. Adoption requires a Forge API token, a public webhook endpoint, a queue worker, a scheduler, and DNS/TLS planning for preview hostnames. Because the repository is archived, expect to adjust Composer constraints or fork before it installs cleanly on a modern Laravel app.
- Does Forge Previewer support Laravel 10, 11, or 12?
- The last release was January 2023, which predates Laravel 10, 11, and 12. It likely pins older illuminate/*, Guzzle, and Forge SDK constraints that can conflict with a current application. There is no maintained upstream support for newer Laravel versions, so a fork with upgraded dependencies is the realistic path.
- What Laravel Forge API token permissions does Forge Previewer need?
- It needs a Forge API token with enough scope to create and destroy sites or servers and trigger deployments. That is account-level write access, so isolate it to a dedicated Forge organization or team where possible. Use the minimum scope that still allows provisioning and cleanup, and monitor for leaked billable resources.
- How does Forge Previewer handle DNS and SSL for preview URLs?
- Preview deployments need a wildcard DNS record and a TLS strategy for per-PR hostnames. If each preview gets a new hostname, Let's Encrypt issuance limits of roughly 50 certificates per registered domain per week become a real ceiling. Plan wildcard certificates or a shared preview domain rather than assuming unlimited automatic issuance.
- Do I need a queue worker and scheduler to run Forge Previewer?
- Yes. Provisioning is slow and should run on a queue worker, while a scheduler is needed for cleanup of stale preview environments. The webhook endpoint should respond quickly and dispatch jobs for Forge API calls. Running everything synchronously in the request is not a production setup.
- Does Forge Previewer work with GitHub, GitLab, or both?
- Forge Previewer is built around pull-request webhooks from a Git provider, and the evaluation notes GitHub and GitLab as the intended integration points. You must verify that your provider's current webhook event schema matches the package's handling, especially for PR opened, synchronized, closed, and merged events. If you need both providers, budget extra integration work.
- Is Forge Previewer still maintained and safe to use in production?
- Treat it as high risk rather than a supported production dependency. The repository is archived, has no security disclosure process, and holds a broadly scoped Forge token that can create billable infrastructure. A bug, replayed webhook, or failed cleanup can provision servers or leak costs, so use it only as a reference implementation you fork, review, and own.
- What are alternatives to Forge Previewer for Laravel preview deployments?
- If you are on Laravel Forge, alternatives include building a small in-house service against the maintained Forge SDK, using your CI provider to call Forge APIs, or adopting a platform with native per-PR environments such as Vapor, Ploi, or Kubernetes-based preview namespaces. The package only fits Forge-hosted Laravel apps and does not solve preview environments for other hosting models.
- How do I test Forge Previewer webhooks and provisioning locally?
- You need a publicly reachable HTTPS webhook endpoint, so use a tunnel or staging host rather than localhost alone. Test against an isolated Forge organization and a non-production server, verify HMAC signature checks, and mock Forge API calls where possible. Because community documentation is thin, expect to read the source and test cleanup paths deliberately.
- Should I fork Forge Previewer or build my own preview deployment service?
- Given the archived status, fork-and-own is the safer path if you are already a Forge shop and want the existing webhook flow. Pin Composer constraints, upgrade illuminate/* and the Forge/GitHub clients, add tests, and take ownership of security patches. If you need current provider schemas or strict isolation, a one-to-two-week in-house build against the maintained Forge SDK may be cheaper over twelve months.