- What is ShieldCI for Laravel and what does it check?
- ShieldCI for Laravel is an automated code analysis package for Laravel applications. Its open-source edition includes 73 analyzers covering security, performance, reliability, code quality, and best practices, and ShieldCI Pro adds 82 more for 155 total checks. It is intended to catch common misconfigurations, exposed files, and risky settings before release.
- How do I install ShieldCI in a Laravel application?
- Install it as a Composer package with composer require shieldci/laravel and run its Artisan entry point locally or in CI. Normal upgrades are drop-in: v1.19.0 requires no migrations, no config publish, and no API changes for consumers. Check the package requirements for your PHP and Laravel versions before installing.
- Which Laravel and PHP versions are supported by ShieldCI?
- ShieldCI supports Laravel 9 and newer. PHP constraints are defined by the package's Composer requirements, and v1.19.0 is a minor release that assumes unchanged PHP and Laravel constraints. Verify the exact supported PHP range in composer.json for your project before upgrading.
- Can ShieldCI run in CI/CD pipelines and block builds?
- Yes. ShieldCI is designed to run as a CI gate alongside static analysis and dependency auditing, and it has no runtime footprint in production request paths. Because check outcomes can change between releases, pin the package version explicitly and review report diffs when upgrading. It can also be run locally to catch issues before they reach CI.
- What is the difference between ShieldCI open-source and ShieldCI Pro?
- The open-source package includes 73 analyzers across security, performance, reliability, code quality, and best practices. ShieldCI Pro adds 82 additional analyzers for a total of 155 checks. Choose the open-source edition for core Laravel checks and Pro when you need broader coverage.
- How do I suppress false positives or disable a specific ShieldCI check?
- ShieldCI reports findings at severity tiers, and teams can use check-level disable or allowlist mechanisms to accept known risks. Because severity and pass/fail semantics can change between releases, review baseline diffs after upgrades before suppressing anything. Record each suppression decision so policy changes are explicit.
- Why did my ShieldCI build start failing after upgrading to v1.19.0?
- v1.19.0 is behaviorally non-neutral: missing-error-tracking now correctly fails when an error tracker is present only under require-dev, so teams that intentionally keep Flare, Inspector, or Nightwatch as dev-only tooling may see a new failure. The asset-cache-headers check also downgrades unfetchable assets from High to a warning, and asset probing now respects the configured asset base instead of assuming app.url. Diff the post-upgrade report against your baseline, then remediate or suppress each delta deliberately.
- Does ShieldCI handle CDNs and Laravel Mix asset hosts when checking assets?
- Yes. In v1.19.0 the asset check resolves its probe target from the configured asset base rather than assuming app.url, so projects behind a CDN or using a Laravel Mix asset host get corrected probing automatically. This fixes a real false-positive class but can legitimately change results versus an older baseline. Confirm which host is being probed in your report and document the expected behavior for your environment.
- How does ShieldCI compare with PHPStan, Psalm, or Composer audit?
- ShieldCI is complementary to generic static analysis and dependency auditing rather than a replacement. It focuses on Laravel-specific security, configuration, performance, reliability, code quality, and best-practice checks, while tools like PHPStan, Psalm, and Composer audit cover type analysis and known dependency vulnerabilities. Many teams run them in the same pipeline stage for layered coverage.
- How should I upgrade and maintain ShieldCI safely in a Laravel project?
- Pin ShieldCI to an explicit version, upgrade in a feature branch, and run the audit locally against your current baseline. Diff the report to isolate behavioral changes, decide per finding whether to remediate or suppress, and land the upgrade with the CI policy adjustment in the same change set. For multi-repo organizations, pilot in one repository first and then roll out after confirming signal quality.