Policy profiles and results
ProductionConfiguration, VaporManifest, Runner, explicit custom Check/Result instances and strict/non-strict decisions.
Developer tools / INTERACTIVE WORKSHOP
Preflight v1.1.0Build a release policy report
Review fictional production settings and a deployment manifest. Add fixed-code custom check rows to exercise status aggregation, warning strictness and exception redaction.
01 / CONFIGURE
Choose a scenario. Change the inputs or build a sequence of commands.
02 / RUN
Execute the installed package against a new fictional example.
03 / INSPECT
Follow the result, actual calls, generated output and integration code.
THE WORKBENCH
Make it your example.
Your server-side changes are temporary. External-service examples use local response fixtures. Start with sample data.
Start with a preset, or change the input and run it.
The behavior is the example.
Your result will show the values, decisions and generated output from the actual package.
Calls used by this scenario. The handbook explains setup, authorizers, storage and error recovery.
The complete response is shown as data. Wide PHP integers are transported as exact decimal strings. Values are never evaluated as PHP or JavaScript.
Run an example to inspect its response.
The last two successful run states stay in this tab’s memory. Run a changed example to compare the actual package results.
What you can exercise here.
Secret redaction
A fixed thrown fixture marker is omitted by the actual Runner.
Real release bindings
Encrypted-file archive guards, real filesystem packaging, cloud bindings and connectivity require a trusted deployment host; no live environment is inspected here.
UNDERSTAND THE BEHAVIOR
Readiness checks should be repeatable and read-only.
Edit fictional production settings, a Vapor manifest and bounded custom-check data. Compare each result with strict and non-strict aggregate decisions.
Choose the checks you actually want
The profile selects ProductionConfiguration, VaporManifest or both. Configuration is constructed from the controls, never from this website’s environment. The manifest is an editable array; the workshop makes no AWS calls.
Warnings and failures aggregate differently
Runner returns structured check results and exposes strict and non-strict pass decisions together. A warning prevents strict success, while a failed check prevents both. Changing the selected strictness does not rewrite the underlying findings.
Shared state is a deployment requirement
The same cache/session choices can be acceptable for one host and unsuitable when require_shared_state is enabled. Cipher and key-shape fixtures exercise actual validation without displaying a real application key.
Custom rows configure trusted host code
The custom-check builder selects pass, warn, fail or throw and a message for a fixed Check implementation. It never accepts executable code. Runner converts an exception into a safe failed result and redacts the thrown marker.
GO FURTHER
Try the boundary cases.
Isolate a production failure
Choose the production profile with ready settings, then enable debug only. Expected: the debug finding changes and passes_selected becomes false. Restore it and test HTTPS and secure cookies individually to identify each check’s responsibility.
Require shared cache and sessions
Run Shared cache and sessions or enable shared with array cache and cookie sessions. Expected: the findings identify the unsuitable shared-state choices. Select appropriate shared drivers and rerun; no real infrastructure is contacted or provisioned.
Compare strict warnings and redacted exceptions
Run A strict warning and toggle strict. Expected: the warning is retained, passes_strict is false and passes_non_strict is true. Run Redact a crashed check: the result fails without exposing its exception message.
Review a broken deployment manifest
Run Broken manifest and inspect its JSON. Repair one malformed or unsafe setting at a time. Expected: actual manifest findings change, independently of production-profile findings. A passing sample is a configuration check, not proof of deployment or a cloud spending cap.
COMPOSE THE RESPONSIBILITIESUseful alone.
Useful alone.
Better when the boundaries fit.
Use Preflight alongside application tests and deployment checks for any of these packages. Add trusted domain checks where infrastructure checks cannot establish workflow readiness or data integrity.