- How do I install cnrp/laravel-instagram-feed?
- Install it with composer require cnrp/laravel-instagram-feed, then publish the package config and migrations and review both before running migrate. Confirm the new table names do not collide with existing tables and that migrate:rollback is clean. After that, add your Instagram credentials and point the package at a writable storage disk for converted media.
- Does this package require Filament?
- Yes. It ships a Composer-installed service provider plus a Filament admin resource for managing Instagram profiles, so a Filament panel is effectively part of the dependency. If your app already runs Filament, adoption is low-ceremony because it slots into an existing admin surface. If it does not, the real cost is the Filament dependency itself, including panel provider setup, assets, authorization conventions, and upgrade cadence, so treat that as an explicit architectural decision rather than an incidental one.
- Which Laravel and PHP versions are supported?
- The technical evaluation assumes Laravel 10, 11, or 12 on PHP 8.1+, but the release notes do not publish a pinned compatibility matrix. Check the package composer.json constraints for Laravel, PHP, and especially the Filament major version before committing. Because it is a v1.0.0 release with unpinned Filament compatibility, a future Filament major bump could strand the package.
- Which Instagram API does it use, and do I need Meta App Review?
- The release notes do not state which API surface is used, so confirm whether it targets the Instagram API with Instagram Login or the deprecated Basic Display API, since that determines whether only Business and Creator accounts work. For production access with non-tester accounts you will typically need Meta App Review and advanced access, which is a multi-week external dependency and the largest schedule risk in the project. Feasibility depends more on Meta credential provisioning than on your codebase.
- How does caching work to reduce Instagram API calls?
- The package includes configuration and caching options intended to keep your feed fresh while avoiding unnecessary API requests. Tune the cache lifetime in the published config so your feed refresh cadence matches how often the source account actually posts. Remember that caching Instagram CDN URLs alone is not enough, because those URLs are short-lived and the media itself must be downloaded and stored.
- How do I display the Instagram feed in my Blade views?
- Fetched posts are persisted through an Eloquent-backed store for profiles and feed items, so your Blade views can render stored items rather than hitting Instagram on every page load. Publish and review the config and migrations, run a fetch, then query the stored items or use whatever view helpers the README documents. Always render from local or disk-stored media, not from Instagram CDN URLs, which expire.
- How are Instagram access tokens refreshed?
- Version 1.0.0 does not include scheduled token refresh, so long-lived Instagram tokens, which typically last around 60 days, must be refreshed manually or by a job you write yourself. Schedule your own refresh command and monitor for auth failures, otherwise this is a scheduled outage waiting to happen in production. This is one of the main operational gaps to plan for before going live.
- Where are images stored, and are they converted to WebP?
- Media goes through a storage-disk pipeline that converts images to WebP, so you need a writable disk such as local storage or S3 plus GD or Imagick compiled with WebP support in your runtime image. Conversion happens on the fetch path with no documented compression settings or disable switch, so watch for CPU spikes and storage growth. No retention or cleanup policy is documented, so plan your own pruning strategy.
- Is media download synchronous or queued, and what happens on partial failure?
- Batch download is listed as planned rather than shipped, so in v1.0.0 expect fetch-time downloads, which means you should run fetching from a queued job or scheduled command instead of a user request. Partial-failure behavior mid-feed is not documented, so test what happens when one item fails and decide whether you need atomic fetches. There is also no documented rate-limit awareness or backoff for the Graph API, so add your own throttling if you fetch frequently.
- Is this package production ready, and how is it maintained?
- The assessment rates technical risk medium-high for a v1.0.0 from a solo or unknown maintainer, driven by Meta API volatility, manual token refresh, unpinned Filament coupling, and short-lived Instagram CDN URLs. Before adopting, verify test coverage, CI status, license, and maintainer bus factor, and review the DB schema footprint and reversibility. If you cannot add Filament, consider forking the fetch and store layer or evaluating a maintained alternative that matches your Laravel and API surface requirements.