Server Management, Self-Hosting, and DevOps Basics

Infrastructure at Different Scales

The right infrastructure depends entirely on what you're running. A marketing site with 500 visitors per day has different needs than an order management system processing 10,000 transactions daily. Over-engineering wastes money and adds operational complexity. Under-engineering causes outages and data loss.

Here's how infrastructure typically evolves as applications grow.

Single Server (0-10,000 daily users)

For most business applications, a single well-configured server handles everything. Web server, application, database, caching, and background workers all run on one machine. This is simpler to manage, cheaper to run, and easier to debug than distributed architectures.

The naive approach is to immediately reach for Kubernetes, load balancers, and multi-region deployments. For a business application serving a few hundred concurrent users, this adds operational overhead without meaningful benefit. A properly tuned single server with good backups and monitoring handles far more load than most people expect.

Separated Database (10,000-50,000 daily users)

As load increases, the database becomes the first bottleneck. Moving the database to its own server provides dedicated resources for queries, independent scaling of compute and storage, and the ability to use managed database services with automated backups and failover.

At this stage, you might run a 4 vCPU / 8GB application server connected to a managed PostgreSQL instance (AWS RDS, DigitalOcean Managed Databases, or similar). The managed database handles backups, minor version upgrades, and basic failover. You focus on the application.

Load Balanced (50,000+ daily users)

When a single application server can't handle the load, add more servers behind a load balancer. This requires stateless application design: sessions stored in Redis rather than local files, file uploads going to object storage rather than the local filesystem, and no application state that can't be shared across servers.

The jump from single server to load balanced adds significant complexity: shared session handling, centralised logging, coordinated deployments, and more moving parts to monitor. Only make this jump when single-server optimisation (caching, query tuning, PHP-FPM tuning) has been exhausted.

Hosting Options and Trade-offs

Choosing where to host involves balancing cost, control, complexity, and capability. There's no universally correct answer. The right choice depends on your team's expertise, compliance requirements, budget, and growth trajectory.

Major Cloud Providers (AWS, Google Cloud, Azure)

These platforms offer everything: compute, storage, databases, networking, serverless functions, machine learning services, and hundreds of other managed services. They're the default choice for applications that need to scale globally or require specific managed services. The choice between cloud platforms and self-hosted solutions is part of the broader own vs rent decision.

AWS is the most mature and has the widest service selection. Google Cloud has strong Kubernetes and data analytics offerings. Azure integrates well with Microsoft enterprise environments. For most Laravel applications, the differences matter less than familiarity. Pick the one your team knows best.

Developer-Focused Clouds (DigitalOcean, Linode, Vultr, Hetzner)

These providers offer simpler, more predictable pricing and fewer services. You get virtual servers, managed databases, object storage, and load balancers. You don't get 300 different managed services, which is often a feature rather than a limitation.

Hetzner deserves specific mention for European hosting. Their dedicated servers offer exceptional price-to-performance ratios (32GB RAM, 8-core Ryzen, 1TB NVMe for around EUR 40/month). For applications with predictable resource needs and no compliance requirement for hyperscaler infrastructure, this represents significant cost savings.

Platform as a Service (Laravel Forge, Ploi, Envoyer)

These tools sit between you and the underlying cloud provider. You bring your own server (from DigitalOcean, AWS, or elsewhere), and they handle server configuration, SSL certificates, deployments, and scheduled tasks. They don't provide hosting; they make managing it easier.

Laravel Forge, for example, configures a fresh Ubuntu server with Nginx, PHP, PostgreSQL or MySQL, Redis, and automated Let's Encrypt SSL. Deployments are triggered by a git push or API call. For Laravel applications specifically, this reduces significant operational overhead without abstracting away server access.

Managed Application Platforms (Laravel Vapor, Heroku, Render)

These platforms handle more of the infrastructure stack. You deploy code; they handle servers, scaling, and operations. The trade-off is less control and higher per-unit costs at scale.

Laravel Vapor runs Laravel on AWS Lambda and related serverless services. No servers to manage, automatic scaling, pay-per-request pricing. The drawbacks: cold starts add latency, debugging is harder without server access, and costs can exceed traditional hosting for consistent high-traffic applications.

Self-Hosted / On-Premises

For applications with strict data residency requirements, extremely high and predictable load, or specific hardware needs (GPU compute, high-memory workloads), running your own servers remains viable. The total cost of ownership includes hardware, networking, power, cooling, physical security, and staff time for maintenance.

Unless you have specific compliance requirements or scale that makes cloud uneconomical, cloud hosting is typically the better choice. The operational overhead of maintaining physical infrastructure rarely pays off below significant scale.

Core Components

Regardless of hosting choice, the same fundamental components appear in every production environment. Understanding how they interact helps diagnose issues and plan capacity.

Web Server (Nginx)

Nginx sits in front of your application, handling incoming HTTP requests. It terminates SSL/TLS connections, serves static files directly (images, CSS, JavaScript), and proxies dynamic requests to PHP-FPM.

A properly configured Nginx instance handles tens of thousands of concurrent connections with minimal resource usage. It should serve static assets with long cache headers, compress responses with gzip or brotli, and forward only dynamic requests to the application server.

Application Server (PHP-FPM)

PHP-FPM (FastCGI Process Manager) runs your PHP code. It maintains a pool of worker processes ready to handle requests. Configuration here directly affects how many concurrent requests your application can handle.

Key settings include pm.max_children (the maximum number of worker processes), pm.start_servers (initial pool size), and pm.max_requests (requests before recycling a worker). A typical configuration for an 8GB server might run 20-30 PHP-FPM workers, each consuming 100-300MB of memory depending on the application.

The naive approach is setting pm.max_children too high, expecting more workers to handle more load. When memory is exhausted, the OOM killer terminates processes unpredictably, causing request failures and potential data corruption. Calculate maximum children based on available memory divided by average worker memory consumption, leaving headroom for the database and operating system.

Database Server (PostgreSQL)

The database is almost always the first bottleneck in web applications. PostgreSQL configuration affects query performance, connection capacity, and durability guarantees.

Critical settings include shared_buffers (typically 25% of available RAM), effective_cache_size (estimate of OS cache available for PostgreSQL), work_mem (memory per operation for sorts and hashes), and max_connections. Most applications need far fewer database connections than expected. 50-100 connections is typically sufficient even for busy applications when using connection pooling.

Connection pooling (using PgBouncer or similar) allows many application workers to share a smaller number of database connections. This reduces PostgreSQL memory overhead and improves connection utilisation. A pool of 20 database connections can serve 100+ PHP workers if most requests don't hold connections for long.

Cache Layer (Redis)

Redis provides in-memory key-value storage for caching, sessions, and queue jobs. It operates in single-digit microseconds for most operations, orders of magnitude faster than database queries.

Common uses include session storage (when running multiple application servers), database query caching, rate limiting, and queue job storage. For most applications, a single Redis instance with a few gigabytes of memory is sufficient. Configure maxmemory and an eviction policy (allkeys-lru for caches, noeviction for sessions and queues) to prevent out-of-memory issues.

Queue Workers

Background job processing handles tasks that shouldn't block HTTP responses: sending emails, generating reports, processing uploads, syncing with external APIs. Laravel's queue system dispatches jobs to Redis, which queue workers consume asynchronously.

Queue workers are long-running PHP processes, typically managed by Supervisor to ensure automatic restart on failure. Size the number of workers based on job characteristics: I/O-bound jobs (API calls, email sending) can run many concurrent workers; CPU-bound jobs (PDF generation, image processing) need fewer workers with more resources each.

Deployment Pipelines and CI/CD

Production deployments should be automated, repeatable, and reversible. Manual deployments via SSH and FTP belong to a previous era. Every deployment should follow the same process, whether triggered by a developer or an automated pipeline.

The Naive Approach

SSH into the server, git pull, run composer install, run migrations, restart PHP-FPM. This works until it doesn't: a migration fails halfway through, the composer install hits a memory limit, or someone forgets to clear the cache. The application is in an inconsistent state, and rolling back requires manual intervention.

The Robust Pattern

Atomic deployments with instant rollback capability. Each deployment creates a new release directory, builds the application, runs health checks, and only then switches the active release. If anything fails, the previous release continues serving traffic.

Rollback is a single command: point the current symlink back to the previous release directory. No rebuild required, instant recovery.

Continuous Integration

Before code reaches production, it should pass automated checks: unit tests, integration tests, static analysis, coding standards. These run on every push, catching issues before they reach production.

A typical CI pipeline for a Laravel application includes: PHPUnit tests (unit and feature tests), PHPStan or Larastan at a reasonable level (level 5-6 catches most issues without excessive strictness), Laravel Pint or PHP-CS-Fixer for code style, and Pest or Dusk for browser tests if applicable.

GitHub Actions, GitLab CI, or similar services run these checks on every pull request. Failed checks block merging to the main branch. This catches regressions before they reach production, not after.

Continuous Deployment

Once code passes CI checks and is merged to the main branch, automated deployment to staging (and optionally production) follows. The deployment pipeline runs the same atomic deployment process described above, with appropriate approval gates for production.

Monitoring and Alerting

Monitoring without alerting is just data collection. Alerting without monitoring is guesswork. Effective observability combines metrics, logs, and traces to answer two questions: is the system healthy right now, and what happened when it wasn't?

What to Monitor

Infrastructure monitoring and application monitoring serve different purposes. Both are necessary.

Focus on the four golden signals: latency (how long requests take), traffic (how many requests), errors (how many fail), and saturation (how full your resources are). These provide a high-level view of system health that applies across all applications.

Alerting Strategy

Alert fatigue is the most common failure mode. When every alert is urgent, no alert is urgent. Teams stop responding to alerts, and real incidents get lost in the noise.

Classify alerts by severity and response expectation:

• Critical (page immediately): Application down, database unreachable, disk 95%+ full. Someone needs to respond within minutes, 24/7.
• Warning (respond during business hours): Error rate elevated, response time degraded, disk 80% full. Needs attention but can wait for the next working day.
• Informational (review weekly): Traffic patterns, deployment events, security scan results. Useful context, not requiring immediate action.

Logging

Centralised logging aggregates logs from all servers and services in one searchable location. When debugging a production issue, you need to correlate events across the web server, application, database, and queue workers. Searching individual server log files doesn't scale.

Tools like Papertrail, Logtail, Datadog Logs, or a self-hosted ELK stack (Elasticsearch, Logstash, Kibana) provide centralised log aggregation. For Laravel applications, send logs to these services via Monolog handlers or by shipping log files with agents like Vector or Filebeat.

Log retention depends on compliance requirements and debugging needs. Seven days catches most immediate issues. Thirty days provides context for recurring problems. Longer retention is typically only necessary for audit and compliance purposes.

Error Tracking

Separate from logging, error tracking services (Sentry, Bugsnag, Flare) capture exceptions with full context: stack traces, request data, user information, and release version. They group similar errors, track error rates over time, and integrate with issue trackers. This visibility is essential for maintaining audit trails and understanding system behaviour.

Every production Laravel application should report exceptions to an error tracking service. The Laravel exception handler integrates with these services in a few lines of configuration. Deploying without error tracking is deploying blind.

Backup and Disaster Recovery

Backups are insurance. You pay the premium (storage cost, operational overhead) hoping you'll never need to claim. But when you do need them, nothing else matters. A backup strategy that fails during recovery is not a backup strategy.

What to Back Up

Data falls into categories with different backup requirements:

• Database (critical): The source of truth for your application. Loss here is typically catastrophic. Back up at least daily, hourly for high-transaction systems.
• User-uploaded files: Documents, images, attachments. May be difficult or impossible to recreate. Back up with the same frequency as database.
• Configuration and secrets: Environment files, SSL certificates, API keys. Store securely, version where possible.
• Application code: Already in version control (git). Not strictly a backup concern, but ensure your git repository is accessible independent of the primary server.

The 3-2-1 Rule

Maintain three copies of critical data, on two different storage types, with one copy offsite. For a typical application: the live database on the primary server, a recent backup on a different volume or server, and an offsite backup in a different provider or region.

Backup Verification

A backup you haven't tested restoring is not a backup. It's a hope. Schedule regular restore tests: monthly for critical systems, quarterly at minimum.

A restore test should verify that the backup file is complete and readable, the restore process completes without errors, the restored data is consistent (referential integrity, no truncation), and the application functions correctly against the restored data.

Automate this where possible. Spin up a temporary server, restore the latest backup, run health checks, report results, and tear down the server. The cost of a few hours of compute monthly is trivial compared to discovering your backups are corrupted during an actual emergency.

Recovery Objectives

Define your recovery objectives before you need them:

These objectives drive backup frequency and recovery architecture. An RPO of 15 minutes requires continuous replication or very frequent backups. An RTO of 1 hour requires hot standby infrastructure, not cold recovery from backups.

Disaster Scenarios

Plan for specific failure modes:

• Server failure: Hardware dies, server becomes unreachable. Recovery: provision new server, restore from backups.
• Data corruption: Application bug or human error corrupts data. Recovery: point-in-time restore to before the corruption occurred.
• Provider outage: Entire availability zone or region unavailable. Recovery: failover to infrastructure in different region (if architected for this).
• Security breach: Attacker gains access, may have modified data. Recovery: restore from known-good backup, forensic investigation, credential rotation.

Document recovery procedures for each scenario. When disaster strikes, stress is high and time is short. Written procedures prevent errors and omissions.

Scaling Strategies

Scaling is not about handling theoretical future load. It's about responding to actual performance constraints. Premature scaling adds complexity, cost, and operational overhead. Profile first, scale second.

Vertical Scaling (Scale Up)

The simplest scaling strategy: give the server more resources. Double the RAM, add more CPU cores, upgrade to faster storage. No application changes required, no distributed systems complexity.

Vertical scaling works until it doesn't. Modern cloud instances go up to 128+ vCPUs and 512GB+ RAM. For most business applications, this ceiling is never reached. When a "2 vCPU / 4GB server can't handle the load", the first response should be to try a 4 vCPU / 8GB server, not to design a microservices architecture.

Horizontal Scaling (Scale Out)

When vertical scaling reaches its limits (cost, availability, or actual hardware limits), add more servers. This requires architectural changes: stateless applications, shared sessions, centralised file storage, and load balancing.

Prerequisites for horizontal scaling:

• Stateless application: No local session storage, no local file uploads, no local cache that can't be lost.
• External session storage: Redis or database-backed sessions accessible by all application servers.
• Object storage for uploads: S3, Spaces, or similar rather than local filesystem.
• Centralised queue: Redis-backed queues accessible by all servers.
• Load balancer: Something to distribute traffic (AWS ALB, DigitalOcean Load Balancers, Nginx, HAProxy).

Once these prerequisites are in place, adding capacity is a matter of provisioning identical servers and adding them to the load balancer. Auto-scaling can spin up servers during peak load and terminate them during quiet periods.

Database Scaling

The database is almost always the hardest component to scale. Unlike stateless application servers, databases hold state and must maintain consistency.

Caching Strategies

Caching is often the most cost-effective scaling strategy. Serving a response from Redis takes microseconds. Serving the same response from a database query takes milliseconds. At scale, this difference translates to significant server cost savings.

Cache at multiple layers:

• HTTP caching: Static assets with long cache headers, CDN for global distribution.
• Full page caching: For pages that don't change frequently or don't vary by user.
• Fragment caching: Cache expensive partials (navigation, sidebars, widgets) separately from page content.
• Query caching: Cache database query results, invalidating when underlying data changes.
• Computed value caching: Cache expensive calculations (reports, aggregations, statistics).

Cache invalidation is famously difficult. Start with time-based expiration (cache for 5 minutes, accept slightly stale data) rather than complex invalidation logic. Only add targeted invalidation when staleness actually causes problems.

Cost Optimisation

Cloud spending is easy to waste. The default is to over-provision, to leave unused resources running, and to use expensive managed services when simpler alternatives suffice. Active cost management typically reduces cloud bills by 30-50% without affecting performance or reliability.

Right-Sizing

Most servers are over-provisioned. Developers provision for peak load plus margin, but peak load may occur 1% of the time. The result: paying for idle capacity 99% of the time.

Monitor actual resource utilisation over time. If CPU averages 20% and peaks at 40%, the server is oversized. Downsize and use the savings to pay for proper monitoring and on-demand scaling capability.

Reserved Capacity

For stable, predictable workloads, reserved instances (AWS) or committed use discounts (GCP) reduce costs by 30-60% compared to on-demand pricing. The trade-off is commitment: you pay regardless of whether you use the capacity.

Reserve your baseline capacity. Handle peaks with on-demand instances. This balances cost savings with flexibility.

Managed vs Self-Managed

Managed services (RDS, managed Redis, managed Elasticsearch) cost more than equivalent self-managed installations. Whether they're worth the premium depends on your team's capacity and expertise.

For a team without dedicated infrastructure staff, managed PostgreSQL is almost certainly worth the 20-30% premium. Automated backups, failover, minor version upgrades, and security patches happen without your involvement. For a team with infrastructure expertise, self-managed databases on cheaper instances may make sense.

The calculation: compare the managed service premium against the fully loaded cost (salary, benefits, overhead) of the staff time required to manage the service yourself. Usually, managed services win unless you're at significant scale.

Egress and Hidden Costs

Cloud providers charge for data leaving their network (egress). These charges appear small (a few cents per gigabyte) but accumulate quickly for applications serving significant traffic or transferring data between regions.

Other commonly overlooked costs: data transfer between availability zones, load balancer per-hour charges, DNS query charges, and support plan costs. Review cloud bills monthly, investigate unexpected line items, and understand pricing before provisioning new resources.

Security Fundamentals

Infrastructure security is not optional. A compromised server affects all applications running on it, all data stored in it, and potentially all other systems it connects to. Security is not a feature; it's a requirement.

System Updates

Unpatched systems are the most common attack vector. Apply security updates promptly. Configure unattended upgrades for security patches. Schedule maintenance windows for updates requiring reboots.

For Ubuntu servers: enable unattended-upgrades for security updates, but require manual intervention for major version upgrades or updates that might affect application behaviour.

Network Security

Minimise attack surface:

• Firewall: Only expose necessary ports. SSH (22), HTTP (80), and HTTPS (443) for web servers. Nothing else. Block everything by default.
• Database access: Never expose databases to the public internet. Connect via private networking or SSH tunnel.
• SSH configuration: Disable password authentication, require key-based authentication. Disable root login, use sudo instead.
• Private networking: Use VPC/private networks between servers. Application servers connect to databases over private IPs, not public internet.

Access Control

Principle of least privilege: grant only the access necessary for each role. Regular audits to remove access that's no longer needed.

• SSH keys: Each person has their own SSH key. When someone leaves, remove their key. No shared keys, no key reuse.
• Service accounts: Applications connect with dedicated service accounts having minimal permissions. The web application's database user doesn't need DROP DATABASE permissions.
• Audit trails: Log who accesses what. SSH access logs, database connection logs, application activity logs. When something goes wrong, you need to know who did what.

Secrets Management

API keys, database passwords, encryption keys: these should never appear in code, version control, or logs.

• Environment variables: The baseline approach. Store secrets in .env files that are not committed to version control.
• Secrets managers: AWS Secrets Manager, HashiCorp Vault, or similar for larger deployments. Centralised secret storage, automatic rotation, access auditing.
• Encryption at rest: Encrypt sensitive configuration. Use application-level encryption for the most sensitive data (credentials, personal information).

SSL/TLS

All traffic should be encrypted. No exceptions. Let's Encrypt provides free certificates with automated renewal. There's no excuse for serving production traffic over plain HTTP.

Configure strong TLS: TLS 1.2 or 1.3 only (disable older versions), strong cipher suites, HSTS headers to prevent downgrade attacks. Test configuration with SSL Labs or similar tools.

Infrastructure as Code

Manual server configuration doesn't scale and doesn't survive disasters. If your only documentation of server configuration is "what's currently running on the server", you'll struggle to reproduce it when needed.

Configuration Management

Tools like Ansible define server configuration as code. Packages to install, services to configure, files to create, users to set up: all defined in version-controlled playbooks that can be re-run to bring a server to known state.

Benefits: new servers can be provisioned identically, configuration drift is eliminated, changes are reviewed and audited through normal code review processes, and disaster recovery is faster because you're restoring configuration from code rather than memory.

Infrastructure Provisioning

Terraform or similar tools define infrastructure itself as code: servers, networks, databases, load balancers, DNS records. Create, modify, or destroy infrastructure through version-controlled configuration files.

For smaller deployments, manual provisioning via cloud console is acceptable. As infrastructure grows, the value of infrastructure as code increases: reproducibility, change tracking, peer review of infrastructure changes, and the ability to create identical environments for staging and production.

Container Orchestration

Docker packages applications with their dependencies into portable containers. Kubernetes orchestrates containers at scale: deployment, scaling, networking, health checks, and service discovery.

For most Laravel applications, containers add complexity without proportional benefit. The primary advantages (portability, reproducible builds) are also achievable with simpler tooling. Kubernetes specifically is significant operational overhead for teams not already experienced with it.

When containers make sense: microservices architectures, applications requiring multiple distinct runtimes, teams with existing container expertise, or organisations standardised on Kubernetes. For a typical Laravel monolith, traditional deployment to well-managed servers is simpler and sufficient.

What You Get

Well-designed infrastructure is invisible. It's the absence of problems, not the presence of features. When infrastructure is working, nobody notices.

• ✓
  Stays up Monitoring catches problems before users notice. Alerting gets the right people involved at the right time.
• ✓
  Deploys safely Atomic deployments with instant rollback. Push to production without holding your breath.
• ✓
  Recovers quickly Tested backups, documented procedures, practiced recovery. When things go wrong, you know what to do.
• ✓
  Scales sensibly Right-sized for current needs, with a clear path to grow. No over-engineering, no premature optimisation.
• ✓
  Costs appropriately Paying for what you use, not what you might need someday. Regular review and optimisation.
• ✓
  Stays secure Updates applied, access controlled, secrets managed, attack surface minimised.

Your application runs reliably. Deployments happen without drama. Problems are caught early. You sleep through the night.