Securing Your Laravel Deployment: SSH Keys, Firewall Rules & Encrypted Credentials

Every Laravel application that leaves your local machine becomes a target. It does not matter whether you are running a side project with fifty users or a SaaS platform processing thousands of requests per minute — the moment your server is reachable on the public internet, automated scanners will find it. Within hours of provisioning a new VPS, you will see brute-force SSH attempts in your logs, probes against common CMS paths, and requests testing for known vulnerabilities in outdated software.

The good news is that securing a Laravel deployment does not require a dedicated security team or an enterprise budget. It requires discipline, the right defaults, and a deployment platform that enforces best practices from the start. In this guide, we will walk through the three pillars of deployment security: SSH key management, firewall configuration, and encrypted credential handling. Along the way, we will show how Deploynix automates much of this work so you can focus on building your application instead of hardening infrastructure.

SSH Keys: Your First Line of Defense

Why Passwords Must Go

Password-based SSH authentication is the single most common vector for unauthorized server access. Attackers run distributed brute-force campaigns that cycle through millions of password combinations. Even a strong password provides only marginal protection compared to SSH key-based authentication, which relies on asymmetric cryptography that is computationally infeasible to brute-force with current hardware.

When you provision a server through Deploynix, password authentication is disabled by default. The platform generates an SSH key pair for server management and allows you to add your own public keys for personal access. This is the correct default — no server should ever accept password logins over SSH in a production environment.

Generating a Secure SSH Key Pair

If you do not already have an SSH key, generating one takes thirty seconds:

ssh-keygen -t ed25519 -C "[e-mail]"

The Ed25519 algorithm is preferred over RSA for new keys. It produces shorter keys with equivalent or superior security, and signature verification is faster. If you need RSA compatibility for legacy systems, use at least 4096 bits:

ssh-keygen -t rsa -b 4096 -C "[e-mail]"

Store your private key with a passphrase. Yes, this adds a step when connecting, but it means a stolen private key file alone is not enough to access your servers. Use ssh-agent to cache the decrypted key in memory so you only enter the passphrase once per session.

Key Management at Scale

Managing SSH keys becomes complicated when your team grows. Each developer needs access to specific servers, and when someone leaves the team, their key must be revoked everywhere. This is where a deployment platform earns its keep.

Deploynix lets you manage SSH keys at the server level. You can add public keys to specific servers, and access is controlled through organization roles — Owner, Admin, Manager, Developer, and Viewer. When a team member leaves, audit the SSH keys on each server they had access to and remove their keys. Make this part of your offboarding checklist.

Hardening SSH Configuration

Beyond key-based authentication, several SSH configuration changes reduce your attack surface:

• Disable root login. Use a non-root user with sudo privileges. Deploynix provisions a dedicated deploynix user for this purpose and restricts root login during provisioning.
• Change the default port. Moving SSH off port 22 eliminates most automated brute-force noise. It is not security through obscurity — a determined attacker will port scan — but it dramatically reduces log noise and automated attacks. You can configure a custom SSH port through your server's firewall rules.
• Limit authentication attempts. Configure MaxAuthTries to a low value like 3 in your SSH config.
• Use AllowUsers or AllowGroups. Explicitly whitelist which users can SSH into the machine.

Deploynix automatically disables password authentication and restricts root login during server provisioning. For additional hardening measures like changing the SSH port, limiting auth attempts, or whitelisting users, you can apply these manually through the web terminal or SSH.

Firewall Rules: Controlling What Gets In

The Principle of Least Privilege

A firewall should deny everything by default and explicitly allow only the traffic your application needs. This sounds obvious, but the number of production servers running with no firewall — or with overly permissive rules — is staggering.

A typical Laravel application needs exactly three inbound ports:

• Port 80 (HTTP): For Let's Encrypt certificate validation and HTTP-to-HTTPS redirects.
• Port 443 (HTTPS): For your application traffic.
• Your SSH port: For server management.

Everything else should be blocked. Your MySQL database does not need to accept connections from the internet. Your Valkey cache server definitely does not need to be publicly accessible.

Deploynix Firewall Management

Deploynix provides a firewall management interface that lets you define rules without touching iptables or ufw directly. When you provision a server, a sensible default ruleset is applied automatically. You can then add custom rules for specific use cases.

For a multi-server architecture, you will need to open additional ports between your servers. For example, your web server needs to reach your database server on port 3306 (MySQL) or 5432 (PostgreSQL). But these ports should only be accessible from your web server's IP address, not from the entire internet.

When setting up a multi-server architecture, use Deploynix's firewall management to add rules that allow traffic only from your web server's IP address to the database port. This keeps the database port closed to the public internet while allowing your application servers to connect.

Common Firewall Mistakes

Opening ports for debugging and forgetting to close them. You temporarily expose port 3306 to run a query from your local machine, then forget to remove the rule. Deploynix's firewall UI makes it easy to audit your rules and remove temporary entries.

Not restricting outbound traffic. Most teams focus exclusively on inbound rules, but outbound restrictions can limit the damage if your server is compromised. A compromised server that cannot make arbitrary outbound connections is significantly harder for an attacker to exploit.

Ignoring IPv6. If your server has an IPv6 address and your firewall only covers IPv4, you have an open door. If your cloud provider assigns an IPv6 address, ensure your firewall rules cover both protocols.

Encrypted Credentials: Secrets That Stay Secret

The .env Problem

Laravel's .env file is both a blessing and a curse. It cleanly separates configuration from code, but it creates a single file containing every secret your application needs — database passwords, API keys, mail credentials, encryption keys. If an attacker gains read access to this file, they have everything.

Common mistakes with .env files include:

• Committing .env to version control (check your .gitignore immediately).
• Copying .env files between environments via insecure channels like Slack or email.
• Leaving .env.backup or .env.old files on production servers.
• Using identical credentials across staging and production.

How Deploynix Handles Environment Variables

Deploynix stores your environment variables encrypted at rest. When you set environment variables through the Deploynix dashboard or API, they are encrypted before being stored in the database. During deployment, they are written to the .env file on your server with appropriate file permissions (readable only by the application user).

This approach means your secrets never pass through insecure channels. You set them once through the dashboard or API, and the deployment process handles the rest. There is no need to SSH into the server and manually edit the file.

Laravel's Built-in Encryption

Laravel also provides php artisan env:encrypt, which encrypts your entire .env file using a key you specify. The encrypted file can be safely committed to version control, and Laravel will decrypt it at runtime.

This is useful for teams that want their environment configuration versioned alongside their code. However, it introduces key management complexity — you need a secure way to distribute the decryption key to your deployment process. Deploynix's approach of managing environment variables directly sidesteps this issue entirely.

Credential Rotation

Secrets should be rotated regularly. Database passwords, API keys, and encryption keys should all have a defined rotation schedule. When you rotate a credential, the process should be:

1. Generate the new credential.
2. Update the credential in your deployment platform (Deploynix dashboard or API).
3. Deploy the application to pick up the new value.
4. Verify the application is working with the new credential.
5. Revoke the old credential.

Never revoke the old credential before deploying with the new one, or you will have downtime. Deploynix's zero-downtime deployment ensures the new credential is active before the old application process is terminated.

Beyond the Basics: Defense in Depth

Keep Software Updated

Deploynix provisions servers with the latest stable versions of PHP, Nginx, and your chosen database. But software updates are ongoing. Security patches for PHP, OpenSSL, and the Linux kernel are released regularly, and applying them promptly is critical.

SSL Certificates

Every production Laravel application must run over HTTPS. Deploynix automates SSL certificate provisioning through Let's Encrypt, including automatic renewal before expiry. For vanity domains using *.deploynix.cloud, wildcard certificates are managed automatically.

For custom domains, Deploynix supports DNS-based validation through Cloudflare, DigitalOcean, AWS Route 53, and Vultr, making wildcard certificate provisioning straightforward even for complex domain setups.

Database Backups

A compromised server is bad. A compromised server with no backups is catastrophic. Deploynix supports automated database backups to AWS S3, DigitalOcean Spaces, Wasabi, and any S3-compatible storage provider. Configure daily backups at minimum, and test your restore process regularly. A backup you have never restored is a backup you cannot trust.

Web Application Firewall Considerations

A network firewall controls which ports are accessible. A web application firewall (WAF) inspects HTTP traffic for malicious payloads — SQL injection attempts, cross-site scripting, and other application-layer attacks. While Laravel's built-in protections (CSRF tokens, parameterized queries, output escaping) handle the most common attack vectors, a WAF adds an additional layer of defense.

If your application handles sensitive data or operates in a regulated industry, consider placing a WAF like Cloudflare's in front of your Deploynix-managed servers.

A Security Checklist for Your Next Deployment

Before you deploy your next Laravel application, verify each of these items:

• SSH password authentication is disabled.
• All team members use SSH keys with passphrases.
• SSH access is restricted to a non-root user.
• The firewall blocks all ports except those explicitly needed.
• Database and cache ports are not publicly accessible.
• Environment variables are managed through the deployment platform, not manually copied.
• .env is in .gitignore and no secrets exist in version control history.
• SSL certificates are provisioned and auto-renewing.
• Database backups are configured and tested.
• Server software is on a regular update schedule.

Conclusion

Securing a Laravel deployment is not a one-time task — it is a continuous practice built on sensible defaults and consistent habits. SSH keys eliminate the largest class of brute-force attacks. Firewall rules ensure only necessary traffic reaches your servers. Encrypted credential management removes the human errors that lead to leaked secrets.

Deploynix automates the foundational security measures so that every server you provision starts from a hardened baseline. But automation is not a substitute for understanding. Knowing why these measures matter — and what happens when they are missing — makes you a better developer and a more reliable operator of production systems.

Security is not about perfection. It is about raising the cost of attack above the value of the target, and doing so consistently across every server, every deployment, and every team member change. Start with the fundamentals, automate what you can, and audit what you cannot.