Server and Deployment Guide: Requirements, Security, Performance, and Operations

This guide explains what you need to run a modern web application reliably and securely. It covers hardware, PHP and database settings, web server configuration, TLS/HTTPS, performance and caching, security hardening, backups, scaling, monitoring, and deployment tools. Read sections that match your role — ops, developer, or site owner — and use the concrete examples and simple checks to get started.

Scope and purpose

This document lists practical, actionable requirements and recommendations for deploying a PHP-based web application (or similar). It helps you:

• Verify minimum hardware and software to run the app.
• Configure PHP, database, and web server settings.
• Improve performance with caching and CDN strategies.
• Harden the server to reduce common risks.
• Plan backup, scaling, and monitoring for production use.
• Choose deployment and management tools for safe releases.

Follow the sections applicable to your environment and adapt values to your traffic and budget.

Minimum server requirements

Start small but realistic. Minimum specs assume a low-traffic production site (tens to a few hundred daily users). Scale up for higher traffic.

• CPU: 2 vCPU (modern cores, e.g., Intel Xeon or AMD EPYC)
• Memory: 4 GB RAM (8 GB recommended)
• Storage: 40 GB SSD (fast NVMe preferred) with separate disk or volume for backups
• Network: 100 Mbps uplink or better; consider location near users
• OS: Recent LTS Linux (Ubuntu LTS, Debian stable, CentOS/Rocky/Alma)
• Access: SSH with key-based auth; no password SSH for production

These are minimums. If your app uses heavy image processing, data analytics, or serving many users concurrently, increase CPU and RAM accordingly.

Recommended PHP configuration and extensions

Use a supported PHP version and enable extensions your app needs. Security and performance are better on newer releases.

• PHP version: PHP 8.1 or 8.2 (use the latest supported minor release)
• SAPI: php-fpm (recommended) for Nginx or Apache with mod_proxy_fcgi

Important PHP settings to check:

• memory_limit: 256M (adjust up for heavy scripts)
• post_max_size / upload_max_filesize: set for your upload needs
• max_execution_time: 30–60s (adjust for long processes)
• realpath_cache_size: 4096k (helps path lookups)
• opcache.enable=1 and opcache.memory_consumption ≥128M
• session.save_path on a fast disk and proper permissions

Essential PHP extensions:

• PDO and PDO driver for your DB (pdo_mysql, pdo_pgsql)
• mbstring
• intl
• json
• openssl
• curl
• xml
• zip
• gd or imagick (for image processing)
• redis or memcached (if you use those caches)
• fileinfo

Security-related PHP options:

• disable_functions: disable dangerous functions like exec, shell_exec, system if not needed
• expose_php = Off
• session.cookie_httponly = 1
• session.cookie_secure = 1 (when using HTTPS)

Database requirements and configuration

Choose a managed database or run your own. Common choices are MySQL/MariaDB or PostgreSQL.

Minimum server-side requirements:

• MySQL 5.7+ / MariaDB 10.3+ or PostgreSQL 12+ (prefer the latest stable release available)
• Use InnoDB (MySQL) or native Postgres storage
• Set charset to utf8mb4 and use appropriate collation (e.g., utf8mb4_unicode_ci for MySQL) to support emojis and international text

Key configuration tips:

• max_connections: configure for expected concurrency; don’t over-allocate
• innodb_buffer_pool_size: 50–75% of available RAM on dedicated DB server
• query_cache_type: OFF for MySQL 5.7+ (deprecated), rely on modern caching
• slow_query_log: enabled and monitored
• binary logging: enable for point-in-time recovery (MySQL/MariaDB)
• autovacuum tuning for PostgreSQL if needed

Operational practices:

• Use read replicas for heavy read workloads.
• Keep regular schema and index maintenance tasks (ANALYZE, OPTIMIZE as applicable).
• Limit direct DB access; use app connection pooling if supported.

Web server options and rewrite rules

Two common choices: Nginx (recommended for static and proxy workloads) and Apache (good for legacy .htaccess setups).

Nginx server block skeleton:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example/public;

    # Redirect to HTTPS
    return 301 https://$host$request_uri;
}

Nginx HTTPS with basic PHP handling:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~* .(css|js|png|jpg|jpeg|gif|svg|ico)$ {
        expires 7d;
        add_header Cache-Control "public";
    }
}

Apache basics (with mod_rewrite):

• Enable modules: rewrite, proxy_fcgi, ssl
• Use a VirtualHost configuration and disable .htaccess for performance; move rules to the site config.

Example Apache rewrite for friendly URLs:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ index.php [L,QSA]
</IfModule>

Make sure your server allows URL rewriting and that the web root is set to the public folder of your application.

TLS/SSL and HTTPS requirements

HTTPS is mandatory for user privacy and modern browsers.

Key requirements:

• Use TLS 1.2 and 1.3 only; disable TLS 1.0 and 1.1.
• Obtain certificates from a trusted CA (Let’s Encrypt is free and automatable).
• Redirect all HTTP traffic to HTTPS (301 redirect).
• Enable HSTS (with caution): start with a short max-age and gradually increase.
• Use secure ciphers and prioritize forward secrecy.

Practical steps:

• Automate certificate renewal (certbot or ACME client).
• Configure OCSP stapling if supported.
• Test your configuration with SSL Labs and fix high-risk warnings.
• Set Referrer-Policy, Content-Security-Policy, and other security headers as appropriate.

Performance, caching, and CDN recommendations

Good caching and CDN use reduce load and improve user experience.

Caching layers to consider:

• Opcode cache: PHP OPcache (always enable in production).
• Object cache: Redis or Memcached for session and query caching.
• HTTP reverse cache: Varnish in front of app servers for cacheable routes.
• Browser caching: set long expires for static assets with cache busting for updates.

CDN:

• Use a CDN (Cloudflare, Fastly, AWS CloudFront, etc.) to serve static assets and offload TLS.
• Cache APIs and static files at CDN edge when safe.
• Purge CDN cache automatically on deploy.

Other performance tips:

• Enable HTTP/2 or HTTP/3 where possible.
• Use Brotli or gzip compression for text assets.
• Minify and bundle CSS/JS, and optimize images (WebP where appropriate).
• Use lazy loading for images and defer non-critical scripts.
• Profile slow database queries and add indexes where needed.

Security best practices and hardening

Security is multi-layered: server, app, and network.

Server hardening:

• Keep OS and packages updated via a package manager and controlled patch cycles.
• Use a firewall (ufw, firewalld, or cloud security groups) and only open required ports.
• Disable root SSH login and use SSH keys; consider 2FA for admin access.
• Run services under separate unprivileged users.

App and PHP security:

• Keep dependencies updated and scan for vulnerabilities.
• Validate and sanitize all external input; use prepared statements for DB access.
• Limit PHP permissions and use open_basedir to restrict file access.
• Store secrets in environment variables or a secrets manager (do not commit them).

Network and monitoring:

• Use intrusion detection or fail2ban for common attack patterns.
• Monitor for suspicious processes, login attempts, and file changes.
• Enforce least privilege for service accounts and databases.

File system permissions:

• Web root should be owned by a deploy user; writable dirs (uploads, cache) should be tightly limited.
• Use immutable flags or read-only mounts for static code when appropriate.

Backup, recovery, and retention policies

Backups must be automated, tested, and stored offsite.

What to back up:

• Database (regular full backups and transaction logs for point-in-time recovery).
• Uploaded files and any persistent storage not recreated during deploy.
• Configuration files and infrastructure-as-code.

Backup schedule examples:

• Database: full daily, incremental or binlog/ WAL shipping every few minutes for busy systems.
• Files: daily or hourly for high-change directories.
• Config and code: version-controlled; store in Git.

Retention policy:

• Keep daily backups for 14–30 days.
• Keep monthly backups for 6–12 months.
• Keep at least one offsite or cold backup for disaster recovery.

Test recovery:

• Regularly perform restore drills on staging systems.
• Document recovery runbooks with step-by-step instructions and contact points.

Encryption and access:

• Encrypt backups at rest and in transit.
• Restrict backup access to a small team and log access events.

Scalability, load balancing, and high availability

Plan for growth from the start: separate concerns and remove single points of failure.

Stateless application design:

• Make app servers stateless: store sessions in Redis or database, not local disk.
• Keep uploads in object storage (S3 or S3-compatible) shared across instances.

Load balancing:

• Use a load balancer (cloud LB or HAProxy/Nginx) in front of app servers.
• Configure health checks and automatic removal of unhealthy nodes.

Database scaling:

• Use read replicas for scaling reads.
• Consider clustering (Galera, Patroni) or managed DB services for HA.
• For write-heavy workloads, evaluate sharding and careful partitioning.

High availability patterns:

• Multiple app servers across availability zones.
• Managed databases with automated failover or a multi-master setup if needed.
• Use sticky sessions sparingly; prefer centralized session stores.

Auto-scaling:

• Use autoscaling for horizontal scaling when traffic varies.
• Ensure fast startup time for new instances (pre-warmed images or container images).

Shared file concerns:

• Avoid storing user uploads on single server disks. Use object storage or a distributed filesystem.

Monitoring, logging, and alerting

Visibility is key to reliability. Collect metrics, logs, and alerts.

Metrics to collect:

• System: CPU, memory, disk, network, load.
• App: request rate, error rate, latency, queue lengths.
• Database: connections, slow queries, replication lag.

Logging:

• Centralize logs (ELK/EFK stack, Graylog, or hosted options).
• Log structured JSON where possible to aid searching.
• Rotate logs and set appropriate retention policies.

Alerts:

• Alert on high error rates, high latency, disk full, replication lag, and failed health checks.
• Set thresholds that avoid alert fatigue; use severity levels.
• Include runbooks with alerts so responders know next steps.

Tools:

• Prometheus + Grafana for metrics and dashboards.
• ELK/EFK or Loki for logs.
• PagerDuty, Opsgenie, or similar for on-call and escalation.

Deployment, staging, and management tools

Use automation, branching workflows, and reproducible environments.

CI/CD:

• Use CI for running tests, linters, and builds (GitHub Actions, GitLab CI, Jenkins).
• Use CD pipelines for automated deploys with manual gates for production.

Deployment strategies:

• Blue-green or canary deployments to reduce risk.
• Rolling updates for minimal downtime.
• Atomic releases with symlinked release folders (e.g., Capistrano-style) or container images.

Environment separations:

• Have at least three environments: dev, staging (production-like), and production.
• Staging should mirror production configuration and run the same migrations.

Configuration management and IaC:

• Use Terraform or cloud provider tooling for infrastructure provisioning.
• Use Ansible, Chef, or Puppet for configuration, or container images for immutable infrastructure.
• Store secrets in a dedicated secrets manager (Vault, AWS Secrets Manager).

Containerization and orchestration:

• Docker for reproducible builds.
• Kubernetes for orchestrating large fleets, but use managed services (EKS/GKE/AKS) if you don’t want to run control plane life cycle.
• Use health checks, readiness/liveness probes, and resource requests/limits.

Rollback and emergency:

• Keep deployment artifacts for easy rollback.
• Automate quick rollback steps and test them.
• Maintain a contact list and incident runbook for major outages.

Final notes

Start with sensible defaults, automate repeatable tasks, and test everything: backups, restores, deployments, and failovers. Security and performance are ongoing work — monitor, measure, and iterate. Use this guide as a checklist and adapt thresholds and tools to your specific application and traffic patterns.