spatie/checklist-going-live: A Production Release Checklist

Why spatie/checklist-going-live Covers a Real Launch Gap

spatie/checklist-going-live addresses the gap between having code that appears finished and having a website that works as a public service. Its stated purpose is simple: it is the checklist used whenever a project is going live at Spatie. The intended users are therefore web teams carrying out a production launch, rather than developers looking for a library to add to an application. It brings checks for user-facing behavior and operational configuration into one document.

The repository is not a test runner and does not describe automated enforcement. Its value comes from prompting people to inspect areas that are easy to miss during development. The list includes current desktop and mobile browsers, error pages, metadata, forms, email behavior, redirects, certificates, DNS, monitoring, and backups. It also contains selected infrastructure checks for Laravel-oriented projects, including `artisan`, Forge, Horizon, Supervisor, DigitalOcean, and Amazon.

That mix makes the checklist useful for a broad website review, but it also defines its boundary. Teams using other hosting stacks, deployment platforms, frontend pipelines, or observability services must translate or omit the provider-specific items. The README gives no compatibility matrix and no explanation of which items are mandatory.

How the Checklist Moves From Browser Checks to Live Operations

The checklist follows a broad release-review path. It begins with Browserstack testing across the latest versions of Chrome, IE or Edge, Firefox, and Safari, plus Mobile Safari and Android. The front-end section then examines insecure `http://` asset sources, CSS and Sass linting, webfont configuration, browser configuration for autoprefixer and babel-preset-env, JavaScript lint errors, leftover `console.log` calls, console errors, page weight, asset caching, and Chrome DevTools audits.

Content review follows with manual interaction in an open console. It asks whether strings and images exist and are translated, navigation states are correct, 404, 500, and 503 pages are useful, and pages are free of n+1 problems. The metadata checks include titles, descriptions, Facebook sharing, Open Graph tags, favicons, and Safari pinned-tab behavior. The README explicitly says to repeat the content section for every language.

The later sections move outward from the application to production infrastructure. They cover redirects, Let's Encrypt, SSL Labs, host-file behavior, canonical domain redirects, HTTP status codes, mixed content, indexing headers, DNS propagation, analytics, search indexing, backups, scheduled tasks, Horizon, uptime monitoring, and stale Git branches. This is a manual systems-review model, not a continuous automated control plane.

Adopting the Checklist for a First Production Review

There is no package to install. The repository contains only `README.md`, so adoption means copying or adapting its Markdown checklist into the team's release process. The README does not document cloning the repository, adding a dependency, or running a command, so there is no installation procedure to reproduce.

A first use can begin by making a working copy of `README.md` and assigning each relevant item to a person who can verify it. Items for technologies the project does not use, such as Google Maps or Horizon, should be removed or marked not applicable. The operator should retain the full sequence across browser, front-end, content, back-end, server, DNS, and services review because each section catches a different layer.

The checklist also assumes that the live host file points at the production site. That assumption should be established before testers interpret redirects, cookies, forms, or backend results. For multilingual websites, the content section must be repeated explicitly for every language. Finally, evidence should be attached to release records where the team's process supports it, especially for certificate checks, backups, DNS, and indexing, because the document itself stores only unchecked boxes.

Front-End and Content Checks Expose Browser-Facing Failures

The front-end portion is more than a cleanup list. Searching for `http://` sources catches mixed-content problems before launch, while the webfont check verifies that font services know the live domain. Browserlist configuration matters because the list calls out both autoprefixer and babel-preset-env, meaning a site can produce incorrect browser targeting even when its JavaScript and CSS are valid.

Page weight is evaluated from at least the homepage. The README specifically points to the browser Inspector network or timeline area to find heavy assets and then asks whether those assets are cached. Chrome DevTools audits are run with mobile throttling and then repeated for desktop. These checks address front-end behavior, but they do not define pass or fail thresholds. A team still has to decide what total weight or audit score is acceptable for its project.

The content checks are equally manual. Navigation active states are checked on every page, error pages are expected to contain useful ways back into the site, and forms are submitted with both incorrect and correct values. Newsletter testing includes a valid duplicate subscription to confirm the expected “already subscribed” response. Structured data is linked to Google's testing tool. The limitation is coverage: the checklist can prompt testers, but it cannot enumerate every page, account role, form, or translated route.

DNS, HTTPS, Backups, and Monitoring Form the Operational Boundary

The server section is where the project-specific nature of Spatie's list becomes clearest. It assumes a production model that may include Let's Encrypt, DigitalOcean, Amazon, Forge, Supervisor, Horizon, Oh Dear, and a private server monitor. One documented Horizon command must be supervised from the Forge release directory. The README also asks whether backups are enabled and whether the output of `backup:run` is successful.

Public connectivity is reviewed through several concrete transitions. The `www` hostname should redirect to `non-www`, `http` should redirect to `https`, development DNS records should be removed, and the host file must resolve to the live site. SSL Labs is provided for certificate health, while a DNS propagation service is named. The repository also links separate Spatie tools for HTTP status checking and mixed-content scanning, but it does not document how to install or invoke either linked tool.

This section is useful as a launch reminder, but it is not infrastructure-as-code. There is no configuration file, provider abstraction, or evidence that the checks run automatically. A team on a different platform must replace these entries with equivalent controls. A team that leaves Forge-specific tasks unchecked without adapting the list gains little protection from them.

Maintenance Scope, Release History, and Licence Uncertainty

The repository is not archived, and its last push was on 2026-09-07. That indicates recent repository activity, but the README does not establish a release cadence. There are no GitHub releases, and the README does not describe versioning, compatibility guarantees, or a migration process. The repository contains only `README.md`, so upgrades consist of reviewing changes to the checklist rather than upgrading an installed dependency.

The licence is not identified in the README. Before copying substantial portions into an internal runbook or redistributing an adapted version, a prospective user must inspect the repository's licence file or ask its owner about permitted use. No legal conclusion can be drawn from the absence of a licence statement in the README.

There is also a direct operational cost. Some checks name providers and tools that a new team may not use, while others require access to DNS, hosting, analytics, Google Search Console, monitoring, and production administration. Maintaining a useful local copy means assigning ownership and removing irrelevant items. Leaving every box in place may create misleading ceremony rather than better release control.

Editorial conclusion

Teams preparing a conventional website for production can adopt this repository as a review sheet, especially if their release process already includes responsible owners for browser testing, hosting, monitoring, and content review. It is not suitable as the sole control for automated deployments, security testing, or infrastructure outside the README's scope. Before adoption, verify that every checklist item still matches the project's hosting model, languages, service providers, and release process, because the repository contains no releases, versioned templates, or documented license.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. spatie/checklist-going-live on GitHub