Laravel Production Readiness Checklist: 25 Things to Verify Before Launch

Launching a Laravel application is an important milestone, but a successful deployment involves much more than getting the homepage to load.

A production application must protect user data, handle unexpected failures, process background jobs reliably, manage database growth, and give developers enough visibility to diagnose problems when they occur.

An application can work perfectly on a local machine and still fail under real-world conditions because of incorrect environment variables, missing database indexes, exposed debug information, an unconfigured queue worker, or an unreliable backup strategy.

This guide covers 25 practical checks to review before launching a Laravel application. Use it for a new SaaS product, a business application, an API, or an existing application moving to a production environment.

Who is this checklist for?

1. Developers preparing a Laravel application for production.
2. Founders launching a SaaS product or business platform.
3. Teams maintaining an existing Laravel application.
4. Businesses reviewing the quality and reliability of a software project.

The exact configuration will depend on your Laravel version, hosting environment, application architecture, and operational requirements. Test the checks that apply to your environment before making production changes.

1. Application configuration and deployment

1. Verify production environment settings

Your production environment must use the correct configuration for the live application.

Check that:

1. APP_ENV is set to production.
2. APP_DEBUG is set to false.
3. APP_URL matches the canonical production URL.
4. Database credentials, mail settings, cache settings, and queue connections are correct.
5. Production secrets are not committed to the source repository.

Example production settings:

Replace the example URL with your actual domain. Keep secrets out of version control and use your hosting provider's secure environment configuration wherever available.

Never expose debug output publicly. Detailed exception pages can reveal application internals, file paths, SQL queries, and other sensitive information.

2. Confirm that secrets and credentials are protected

Review the application repository and deployment configuration for exposed credentials.

Check:

1. API keys and third-party service tokens.
2. Database usernames and passwords.
3. Mail server credentials.
4. Payment gateway secrets.
5. Cloud storage credentials.
6. Private keys and webhook signing secrets.

If a secret has already been committed or exposed, removing it from the latest commit is not sufficient. Rotate the affected credential and review its possible misuse.

Do not share production secrets in support tickets, screenshots, logs, or AI coding assistant prompts.

3. Verify file permissions and the public document root

Laravel's web server document root should point to the application's public directory, not the project root.

The project root may contain environment files, dependencies, configuration, and source code that must not be publicly accessible.

Check that:

1. The web server cannot serve .env or other private project files.
2. storage and bootstrap/cache are writable by the appropriate application process.
3. Other application files have only the permissions they need.
4. Uploaded files cannot execute as server-side code.
5. Directory listing is disabled where it is not explicitly required.

Avoid setting every file and directory to 777 to resolve permission errors. Correct ownership and the minimum required permissions are safer.

4. Review dependencies and supported versions

Before deployment, review the PHP version, Laravel version, Composer dependencies, and any frontend build dependencies.

Run the relevant checks in your development or CI environment:

Review any reported incompatibilities and known vulnerabilities. Verify that your Laravel and PHP versions are still supported and compatible with the packages you use.

For production deployment, install dependencies using the appropriate production configuration, such as Composer's --no-dev option, when your deployment process supports it.

Do not update every dependency directly on a live server without testing compatibility first.

2. Security and access control

5. Enforce HTTPS and secure cookies

Use HTTPS for the entire application, including login pages, APIs, admin routes, and authenticated dashboards.

Verify:

1. HTTP requests redirect to HTTPS where appropriate.
2. TLS certificates are valid and renewed automatically.
3. Session cookies use secure settings.
4. Cookie domain and SameSite settings match the application's authentication architecture.
5. Reverse proxy configuration correctly identifies HTTPS requests.

Configure trusted proxies carefully if your application sits behind a load balancer or proxy. Incorrect proxy configuration can cause problems with HTTPS detection and generated URLs.

6. Test authentication and authorization

Authentication answers who the user is. Authorization determines what that user can do.

Test both.

For applications with multiple roles or tenants, verify that:

1. Ordinary users cannot access administrative functions.
2. Users cannot access another user's private records by changing an ID in a URL or API request.
3. Tenant boundaries are enforced in queries and background jobs.
4. Sensitive actions require the correct permissions.
5. Password reset and account recovery flows are secure.
6. Sessions are invalidated appropriately after logout or other security-sensitive events.

Do not rely on hiding a button in the frontend as a security control. Enforce permissions on the server for every protected operation.

7. Validate and sanitize user input appropriately

Use Laravel's validation facilities for requests, form submissions, uploads, and API payloads.

For example:

Adapt the rules to your actual data model and business requirements.

Also review:

1. Mass assignment protection.
2. File upload validation.
3. Output escaping in rendered HTML.
4. Safe handling of rich text and Markdown.
5. Protection against SQL injection through parameterized queries and safe query construction.
6. Rate limits for login, password reset, and sensitive endpoints.

Validation does not replace authorization, and HTML sanitization is particularly important when allowing users to submit rich content.

8. Protect against cross-site request forgery and unsafe cross-origin requests

For browser-based applications that use cookie authentication, verify that state-changing requests are protected by Laravel's CSRF mechanisms.

For API integrations, configure CORS to allow only the origins, methods, and headers that the application actually needs.

Remember that CORS is a browser access policy, not a replacement for authentication or authorization.

If your frontend and backend are hosted on separate domains, test the complete login, session, and logout flow in the actual production configuration.

9. Secure file uploads and downloads

User-uploaded files are a common source of security and storage problems.

Check that:

1. Allowed file types and file sizes are restricted.
2. MIME types are validated rather than trusting the filename extension alone.
3. Private files are stored outside the public web root or in private object storage.
4. Downloads enforce authorization.
5. Public uploads cannot execute as scripts.
6. Image processing and document parsing are appropriately isolated and resource-limited.

For sensitive documents, use authorized download endpoints or short-lived signed URLs rather than permanent public links.

10. Review rate limits and abuse protection

Identify endpoints that could be abused or become expensive to operate.

Examples include login attempts, password resets, search, public forms, report generation, file processing, and AI-powered endpoints.

Use Laravel rate limiting and, where appropriate, infrastructure-level controls.

For paid external APIs, enforce server-side usage limits and spending alerts. Never trust a client-side counter to enforce a user's subscription allowance.

3. Database integrity and performance

11. Verify database indexes and query performance

An application may feel fast with a small test database but become slow when real data accumulates.

Inspect frequently executed queries, especially those used by dashboards, lists, reports, search, and administrative screens.

Look for:

1. Missing indexes on frequently filtered columns.
2. Slow joins and aggregations.
3. Repeated queries inside loops.
4. Unnecessary full-table scans.
5. Queries that load more columns or records than needed.

Use the database's query analysis tools, such as EXPLAIN, to understand expensive queries before adding indexes.

Indexes can improve read performance but also consume storage and add overhead to writes. Design them around actual query patterns.

12. Prevent N+1 queries

An N+1 query problem occurs when the application executes an additional database query for each item in a collection.

For example, accessing a relationship inside a loop can cause repeated queries:

When the relationship is needed, eager loading may reduce the number of queries:

The example is illustrative. Use pagination or bounded queries when working with large datasets rather than loading every record into memory.

Measure query counts and execution time on important pages and API endpoints.

13. Use pagination for growing datasets

Avoid returning an unlimited number of database records in a single API response or admin page.

For ordinary page navigation:

For large, frequently changing datasets, cursor pagination may be more appropriate:

Choose a stable ordering, review indexing, and ensure that the response includes only the fields required by the client.

Pagination limits the size of individual responses. It does not, by itself, fix slow queries or inefficient database access.

14. Use database transactions for related operations

When multiple database changes must succeed or fail together, use a transaction.

For example, a financial operation may involve updating a balance and recording a transaction. A partial update could leave inconsistent data.

Laravel provides transaction support:

Use appropriate locking or concurrency controls where simultaneous requests could update the same records.

Do not assume that a database transaction automatically covers external services, email delivery, payment processing, or messages sent to another system. Those operations need their own reliability strategy.

15. Review database migrations and constraints

Before deployment:

1. Test migrations against a representative copy of the schema.
2. Confirm that required indexes and foreign keys exist.
3. Check for duplicate or invalid data before adding constraints.
4. Identify migrations that may lock large tables.
5. Confirm that the deployment can recover if a migration fails.
6. Take an appropriate backup before high-risk schema changes.

For large production tables, consider backward-compatible, staged migrations instead of combining destructive schema changes with an application release.

A database rollback is not always equivalent to restoring the original data. Plan recovery explicitly.

4. Queues, caching, and application resources

16. Confirm that queue workers actually run

Queued jobs are useful for email, notifications, imports, exports, report generation, and other work that should not block a web request.

Check:

1. The configured queue connection is correct.
2. Workers run continuously under an appropriate process manager or hosting mechanism.
3. Failed jobs are recorded and reviewed.
4. Retry and timeout settings are appropriate for each job.
5. Workers can access required files, credentials, and services.
6. Long-running workers are restarted during deployments when necessary.

For Redis or database-backed queues, inspect the queue backlog and failed-job records.

A command such as queue:work --stop-when-empty is useful for certain scheduled or one-off execution models, but it is not a substitute for a persistent worker when your application requires continuous queue processing.

17. Configure caching deliberately

Laravel supports several caching backends. Select one that matches your hosting environment, workload, and operational constraints.

Review:

1. Configuration and route caching where appropriate.
2. Frequently requested, expensive data.
3. Cache expiration and invalidation.
4. Tenant-specific cache keys.
5. Cache storage capacity and eviction behavior.
6. Whether the chosen cache driver is shared across application instances.

Be careful with user-specific or tenant-specific data. Incorrect cache keys can expose one user's information to another.

Do not cache everything indiscriminately. Measure the bottleneck and invalidate cached values whenever relevant data changes.

18. Check memory consumption and long-running processes

Review memory use for web requests, queue jobs, scheduled tasks, exports, imports, and report generation.

Look for:

1. Unbounded collection loading.
2. Large in-memory file operations.
3. Excessive eager loading.
4. Jobs that accumulate data without releasing resources.
5. Long-running processes that retain stale application state.
6. Requests that exceed configured memory limits.

Use chunking or lazy iteration where suitable, and process large exports in background jobs.

Test with realistic data volumes. A small local dataset cannot reliably demonstrate production memory behavior.

19. Configure sessions and file storage

Confirm that session storage works correctly across all application instances.

For a horizontally scaled application, local file-based sessions may not be suitable unless requests are consistently routed to the same instance and that design is intentional.

Also verify:

1. Session lifetime and expiration.
2. Appropriate cookie settings.
3. Shared storage requirements for uploads.
4. Disk capacity and cleanup policies.
5. Private versus public storage behavior.
6. Recovery and retention of important uploaded files.

Test the actual deployment topology rather than assuming that local development storage will behave identically in production.

5. Reliability, monitoring, and recovery

20. Configure application logging

Logs should help you identify failures without exposing sensitive information.

Verify that:

1. Production logs are being written and retained.
2. Log rotation or retention policies prevent uncontrolled disk growth.
3. Critical exceptions can be identified quickly.
4. Logs include useful context such as request IDs where appropriate.
5. Passwords, access tokens, and unnecessary personal information are not logged.

Centralized logging or an error-tracking service can help teams investigate issues across multiple application instances.

21. Add health checks and operational monitoring

A successful homepage response does not prove that the database, queue, email service, and other dependencies are working.

Monitor relevant signals such as:

1. HTTP error rates and response times.
2. Database connection failures.
3. Queue backlog and failed jobs.
4. Disk and memory usage.
5. Scheduled task failures.
6. External service errors.
7. Availability of critical user workflows.

Use a health endpoint appropriate to your infrastructure. Keep detailed diagnostic information and internal service credentials out of public responses.

22. Verify backups and recovery procedures

A backup is only useful if you can restore it.

Check that:

1. Database backups run on a defined schedule.
2. Important uploaded files are included where required.
3. Backups are protected from unauthorized access.
4. Retention matches your business and legal requirements.
5. Backup failures trigger alerts.
6. Restore procedures are documented and tested.

Choose recovery objectives based on how much data the business can afford to lose and how long it can tolerate an outage.

For a critical application, perform a restore test in an isolated environment before relying on the backup strategy.

23. Verify scheduled tasks and notifications

If the application uses Laravel's scheduler, confirm that the required scheduler invocation is configured correctly for the hosting environment.

Review scheduled commands for:

1. Correct execution frequency.
2. Appropriate time zones.
3. Overlap prevention where necessary.
4. Failure reporting.
5. Idempotency and safe retries.
6. Correct environment configuration.

Test scheduled emails, recurring billing workflows, cleanup tasks, and notifications end to end.

A scheduled task appearing in the codebase does not mean it is running in production.

6. Final deployment and launch checks

24. Test the real deployment process

Run the release procedure in a staging environment or a safe production-like setup.

Verify:

1. Frontend assets are built correctly.
2. Dependencies match the target environment.
3. Required configuration is present.
4. Migrations complete safely.
5. Cache-clearing and cache-rebuilding commands are appropriate.
6. Queue workers and scheduled tasks are ready.
7. The application can recover from a failed deployment.

Document the release and rollback steps.

For applications without shell access, design a deployment process that works within the hosting provider's actual capabilities. Do not assume that every server supports SSH, Node.js, process managers, or long-running workers.

25. Perform a production smoke test

After deployment, test the application's most important user journeys.

Depending on your product, these might include:

1. Homepage and key landing pages.
2. Registration, login, and logout.
3. Password recovery.
4. Creating and editing a record.
5. Access control between roles or tenants.
6. API requests and validation errors.
7. File uploads and authorized downloads.
8. Email and notification delivery.
9. Subscription or payment workflows.
10. Admin functionality and reporting.

Also review HTTP status codes, application logs, queue failures, and monitoring alerts.

Avoid using real customer payments or destructive actions for testing unless the procedure is explicitly designed and authorized for that purpose.

A practical production readiness scorecard

Use this table to record the result of your review.

Mark a check as complete only when you have verified it. If a feature is not relevant to your application, record it as not applicable rather than assuming it is complete.

Do not use a numerical score as a substitute for risk assessment. A single serious authorization vulnerability can outweigh dozens of completed operational checks.

Common mistakes to avoid before launch

Some of the most consequential mistakes are also easy to overlook:

1. Leaving debug mode enabled in production.
2. Assuming that frontend validation is sufficient.
3. Returning entire database tables from APIs.
4. Ignoring failed queue jobs.
5. Storing private documents in publicly accessible directories.
6. Deploying destructive migrations without a recovery plan.
7. Treating successful backup creation as proof that recovery works.
8. Assuming that a working local environment proves the production environment is correctly configured.

Address high-impact security and data-integrity issues before launch, even when other checklist items remain.

Final thoughts

Production readiness is not a one-time task. As your Laravel application grows, traffic patterns change, dependencies evolve, and new features introduce new risks.

Revisit this checklist after major releases, infrastructure changes, authentication updates, payment integrations, and significant increases in data volume.

A reliable application is built through a combination of secure implementation, careful deployment, measurable performance, tested recovery procedures, and ongoing maintenance.

Need help preparing your Laravel application for production?

CodexiLab helps businesses plan, build, and improve software applications, including backend systems, APIs, SaaS platforms, and production engineering workflows.

If you're preparing to launch a product or need help reviewing an existing application, contact CodexiLab to discuss your requirements.

Disclaimer: This checklist provides general engineering guidance, not a guarantee of security, availability, or regulatory compliance. Requirements depend on the application, infrastructure, data, and applicable regulations.