Shipping a Laravel application to production is exhilarating. Watching real users interact with something you built is one of the best feelings in software development. But that excitement can quickly turn to dread if you haven't locked down your server and application against the constant barrage of automated scans, brute-force attempts, and zero-day exploits that every internet-facing service faces within minutes of going live.
This checklist is designed for Laravel developers deploying in 2026. It covers the full stack, from the infrastructure layer up through the application itself, and highlights where Deploynix handles security concerns for you out of the box.
HTTPS Everywhere
There is no excuse for serving any page over plain HTTP in 2026. Search engines penalize unencrypted sites, browsers display scary warnings, and sensitive data transmitted in cleartext is trivially interceptable.
What you need to do:
- Ensure every route, asset, and API endpoint is served over TLS 1.2 or higher (preferably TLS 1.3).
- Redirect all HTTP traffic to HTTPS at the web server level, not just in your Laravel middleware.
- Set
APP_URLin your.envto usehttps://. - Add the
Strict-Transport-Security(HSTS) header with a longmax-agevalue. - If you use a CDN or reverse proxy, confirm that the connection between the proxy and your origin is also encrypted.
How Deploynix helps:
Deploynix provisions free SSL certificates automatically via Let's Encrypt when you add a site. Certificates renew before expiry without manual intervention. For apps using vanity domains (*.deploynix.cloud), a wildcard certificate is provisioned and synced across all your servers. Deploynix's Nginx configuration redirects HTTP to HTTPS by default, and TLS 1.3 is enabled on all provisioned servers.
Firewall Configuration
A properly configured firewall is your first line of defense. The principle of least privilege applies: only open the ports your application actually needs.
Essential rules:
- Allow TCP port 22 (SSH) only from trusted IP addresses or a VPN range.
- Allow TCP ports 80 and 443 for web traffic.
- Allow your database port (3306 for MySQL/MariaDB, 5432 for PostgreSQL) only from your application servers, never from the public internet.
- Allow Valkey's port (6379) only from internal networks.
- Block everything else by default.
How Deploynix helps:
Deploynix manages firewall rules through a clean dashboard. When you provision a server, sensible defaults are applied automatically (SSH, HTTP, HTTPS). You can add, edit, or remove rules from the UI, and they're pushed to the server's ufw configuration instantly. If you deploy a dedicated database server, add a firewall rule through the dashboard to restrict the database port to only your application server's IP address.
SSH Hardening
SSH is the gateway to your server. If an attacker gains SSH access, game over. Hardening SSH is non-negotiable.
Steps to take:
- Disable password authentication entirely. Use SSH key-based authentication only.
- Disable root login over SSH. Use a non-root user with
sudoprivileges. - Change the default SSH port from 22 to a non-standard port (security through obscurity adds a thin layer, but it dramatically reduces automated scan noise).
- Set
MaxAuthTriesto a low value (3 or fewer). - Use
AllowUsersorAllowGroupsdirectives to restrict which system users can log in via SSH. - Enable
fail2banto automatically ban IPs after repeated failed login attempts.
How Deploynix helps:
When Deploynix provisions a server, it creates a dedicated deploynix user with SSH key authentication. Root login is restricted and password authentication is turned off automatically. You manage SSH keys per-server through the Deploynix dashboard. For additional hardening measures like changing the SSH port, setting MaxAuthTries, configuring AllowUsers, or installing fail2ban, apply these manually through the web terminal or SSH.
Protecting Your .env File
Your .env file contains database credentials, API keys, encryption keys, and other secrets that would be catastrophic if exposed. Laravel's .env file is the single most sensitive file in your project.
Best practices:
- Never commit
.envto version control. Ensure.envis in your.gitignore. - Set file permissions to
600(readable only by the file owner). - Verify your web server configuration blocks direct access to dotfiles. Nginx should return a 403 for any request to
/.env. - Rotate your
APP_KEYperiodically, understanding that this invalidates all encrypted data. - Use different credentials for each environment (local, staging, production).
How Deploynix helps:
Deploynix stores environment variables securely and injects them during deployment. The Nginx configuration that ships with every Deploynix site blocks access to dotfiles by default. You can edit environment variables through the dashboard without SSH-ing into the server, reducing the risk of leaving terminal history with sensitive data.
Database Access Control
Your database contains your users' data. Protecting it is both a security and a legal obligation.
Steps to take:
- Never expose your database port to the public internet.
- Create application-specific database users with only the privileges they need (typically
SELECT,INSERT,UPDATE,DELETEon their own database). - Use strong, unique passwords for every database user.
- Enable SSL for database connections if your application and database servers are on different networks.
- Schedule regular backups and test your restore process.
How Deploynix helps:
Deploynix supports MySQL, MariaDB, and PostgreSQL. When you create a database through the dashboard, Deploynix generates a strong password automatically. For dedicated database servers, use the firewall management interface to restrict the database port to only your application server's IP addresses. Backups can be configured to push to AWS S3, DigitalOcean Spaces, Wasabi, or any S3-compatible storage provider, with configurable retention policies.
Dependency Auditing
Your application is only as secure as its weakest dependency. A single vulnerable package in your composer.json or package.json can expose your entire application.
What you should do:
- Run
composer auditregularly to check for known vulnerabilities in PHP dependencies. - Run
npm auditfor JavaScript dependencies. - Pin dependency versions in production. Avoid using wildcard version constraints.
- Subscribe to security advisories for critical packages (Laravel, Symfony components, etc.).
- Update dependencies promptly when security patches are released, but always test in staging first.
- Consider using tools like
roave/security-advisoriesto prevent installing packages with known vulnerabilities.
Automating audits:
Set up a CI/CD pipeline step that runs composer audit and npm audit before every deployment. If vulnerabilities are found above a certain severity, fail the pipeline. You can also add these checks to your Deploynix custom deploy script (configured in the Deploy Script tab) to run during each deployment.
Application-Level Security
Beyond infrastructure, your Laravel code itself needs to be secure.
CSRF protection: Laravel includes CSRF protection out of the box via the @csrf directive. Never disable it globally. If you have specific API routes that need to bypass CSRF (like webhook endpoints), exclude only those routes.
SQL injection: Always use Eloquent or the query builder's parameter binding. Never concatenate user input into raw SQL queries. If you must use DB::raw(), use parameter binding.
XSS prevention: Use Blade's {{ }} syntax, which automatically escapes output. Only use {!! !!} when you explicitly need to render trusted HTML, and sanitize it first.
Mass assignment: Define $fillable on every model. Never use $guarded = [] in production code.
Authentication: Use Laravel's built-in authentication scaffolding. Implement rate limiting on login routes. Consider adding two-factor authentication.
Authorization: Use Gates and Policies to control access to resources. Never rely solely on hiding UI elements for security; always validate permissions server-side.
File uploads: Validate file types, sizes, and contents. Store uploads outside the web root. Use Laravel's Storage facade with a non-public disk.
HTTP Security Headers
Modern browsers support a variety of security headers that can prevent entire classes of attacks.
Headers to set:
-
Content-Security-Policy: Restrict which scripts, styles, and resources can load. Start with a restrictive policy and loosen as needed. -
X-Content-Type-Options: nosniff: Prevent MIME-type sniffing. -
X-Frame-Options: DENYorSAMEORIGIN: Prevent clickjacking. -
Referrer-Policy: strict-origin-when-cross-origin: Control what information is sent in theRefererheader. -
Permissions-Policy: Restrict access to browser features like camera, microphone, and geolocation.
You can set these headers in your Nginx configuration or via Laravel middleware. For a Laravel-specific approach, packages like spatie/laravel-csp make Content Security Policy management straightforward.
Logging and Monitoring
You can't protect what you can't see. Comprehensive logging and monitoring let you detect breaches early and respond quickly.
What to log:
- Authentication events (logins, failed logins, password resets).
- Authorization failures (attempts to access resources without permission).
- Application errors and exceptions.
- Deployment events.
Monitoring essentials:
- Set up alerts for unusual patterns (spike in 403/401 responses, abnormal traffic volumes).
- Monitor disk space, CPU, and memory usage.
- Keep logs for a reasonable retention period (90 days minimum for security investigations).
How Deploynix helps:
Deploynix provides real-time server monitoring on paid plans. You can track CPU, memory, disk usage, and load averages from your dashboard. When thresholds are exceeded, critical alerts are sent via email to the server owner so you can investigate potential security incidents or resource exhaustion attacks.
Keeping Your Server Updated
Unpatched operating systems and software are one of the most common attack vectors.
Best practices:
- Enable unattended security updates on Ubuntu (the default OS for Deploynix servers).
- Schedule a monthly review of available updates for non-security packages.
- Keep PHP, Nginx, and database servers updated to the latest stable versions.
- Subscribe to Ubuntu Security Notices (USN) for your server's OS version.
Deploynix Security Defaults Summary
When you provision a server through Deploynix, the following security measures are applied automatically:
- SSH key-only authentication with root login disabled.
- UFW firewall enabled with restrictive default rules.
- Automatic SSL certificate provisioning and renewal.
- Nginx configured to block access to dotfiles and sensitive paths.
- Non-root deployment user with appropriate permissions.
- Database ports restricted to internal network access.
- PHP configured with production-safe settings (
display_errors = Off,expose_php = Off).
Conclusion
Security is not a one-time task. It's an ongoing process that requires vigilance, regular audits, and prompt responses to new threats. This checklist covers the essentials, but it's not exhaustive. As your application grows, your security posture must grow with it.
Deploynix handles many of the infrastructure-level security concerns automatically, letting you focus on writing secure application code. But no platform can protect you from insecure code practices. Use this checklist as a starting point, review it quarterly, and stay current with the Laravel security advisories and PHP security best practices.
Your users trust you with their data. Honor that trust by making security a first-class priority in every deployment.
Top comments (0)