Sites-Enabled and Sites-Available: Complete Guide for NGINX and Apache

NGINX and Apache remain the two most dominant web servers on the internet — and for good reason. Both are battle-tested, highly configurable, and capable of serving complex, high-traffic websites with ease. One of the most important concepts for any system administrator managing a Linux-based server is understanding how these web servers handle website configuration through the sites-available and sites-enabled directory structure.

Whether you're running a single website or managing dozens of virtual hosts on a VPS Hosting plan, mastering this configuration model will give you precise control over which sites are active, which are staged, and how your server resources are allocated.

This guide provides a comprehensive, step-by-step walkthrough of how to enable, disable, and manage websites using both NGINX and Apache on Linux systems.

Understanding sites-available and sites-enabled

Both NGINX and Apache use a two-directory model to separate site configuration from site activation. This architectural pattern is elegant in its simplicity and extremely powerful in practice.

sites-available

The /etc/nginx/sites-available/ or /etc/apache2/sites-available/ directory acts as a library of all possible site configurations. Every website you intend to host on the server gets its own configuration file stored here. Crucially, files in this directory are not active — they define the configuration but do not serve any traffic until explicitly enabled.

sites-enabled

The /etc/nginx/sites-enabled/ or /etc/apache2/sites-enabled/ directory contains symbolic links pointing to configuration files in sites-available. Only sites with an active symlink in this directory are loaded by the web server and served to visitors.

This separation offers several key advantages:

• Non-destructive disabling: You can deactivate a site without deleting its configuration.
• Rapid deployment: Staging a new site is as simple as creating a symlink.
• Clean organization: All configurations exist in one place, regardless of whether they're active.

Managing Websites with Apache

1. Apache Virtual Hosts Configuration

Apache uses Virtual Hosts to serve multiple websites from a single server instance. Each website gets its own configuration file that tells Apache how to handle incoming requests for that domain — including the document root, logging paths, server aliases, and more.

Configuration files for Apache virtual hosts are stored in:

/etc/apache2/sites-available/

#### Creating a Virtual Host Configuration File

To create a configuration file for a site called test.oo.md, run:

sudo nano /etc/apache2/sites-available/test.oo.md.conf

Inside the file, define your virtual host block:

<VirtualHost *:80>
    ServerAdmin admin@test.oo.md
    ServerName your_domain_or_IP
    ServerAlias www.test.oo.md
    DocumentRoot /var/www/test.oo.md

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

> Note: Replace your_domain_or_IP with your actual domain name or server IP address. The ServerAlias directive allows Apache to respond to the www subdomain as well.

Save and exit the file when finished.

2. Enable the Site with a2ensite

Once the configuration file is in place, activate the site using the a2ensite command (Apache 2 Enable Site):

sudo a2ensite test.oo.md.conf

This command automatically creates a symbolic link from sites-available to sites-enabled:

/etc/apache2/sites-enabled/test.oo.md.conf -> /etc/apache2/sites-available/test.oo.md.conf

The site is now queued to be served, but changes won't take effect until Apache is reloaded.

3. Test the Apache Configuration

Before reloading Apache, always validate your configuration syntax to catch any errors:

sudo apachectl configtest

A successful output will show:

Syntax OK

If there are errors, Apache will describe the problem and the line number — fix these before proceeding.

4. Reload Apache to Apply Changes

sudo systemctl reload apache2

Using reload instead of restart is preferred in production environments because it applies the new configuration without dropping active connections.

5. Disable a Site with a2dissite

To take a site offline without deleting its configuration, use the a2dissite command:

sudo a2dissite test.oo.md.conf

This removes the symbolic link from sites-enabled. The configuration file in sites-available remains untouched. Reload Apache to apply:

sudo systemctl reload apache2

Managing Websites with NGINX

1. NGINX Server Block Configuration

NGINX uses Server Blocks — the functional equivalent of Apache's Virtual Hosts. Server block configuration files are stored in:

/etc/nginx/sites-available/

#### Creating a Server Block Configuration File

To create a configuration file for test.oo.md, run:

sudo nano /etc/nginx/sites-available/test.oo.md

Define your server block inside the file:

server {
    listen 80;
    server_name test.oo.md www.test.oo.md;

    root /var/www/test.oo.md;
    index index.html index.htm;

    access_log /var/log/nginx/test.oo.md_access.log;
    error_log  /var/log/nginx/test.oo.md_error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

> Key directives explained:

> – listen 80 — Instructs NGINX to listen for HTTP traffic on port 80.

> – server_name — Defines which domain names this block responds to.

> – root — Sets the document root directory for the site's files.

> – try_files — Attempts to serve the requested file or directory; returns a 404 if not found.

2. Enable the Site by Creating a Symbolic Link

Unlike Apache, NGINX does not provide a built-in command like a2ensite. Instead, you manually create the symbolic link:

sudo ln -s /etc/nginx/sites-available/test.oo.md /etc/nginx/sites-enabled/

This links the configuration file into the sites-enabled directory, making it eligible to be loaded by NGINX.

3. Test the NGINX Configuration

Always test your NGINX configuration before reloading:

sudo nginx -t

A successful test returns:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If errors are reported, review the indicated lines in your configuration file and correct them before proceeding.

4. Reload NGINX to Apply Changes

sudo systemctl reload nginx

As with Apache, reload gracefully applies configuration changes without interrupting active connections — always preferred over a full restart in live environments.

5. Disable a Site in NGINX

To disable a site, remove its symbolic link from the sites-enabled directory:

sudo rm /etc/nginx/sites-enabled/test.oo.md

Then reload NGINX to apply the change:

sudo systemctl reload nginx

The configuration file in sites-available is preserved and can be re-enabled at any time.

Quick Reference: Apache vs. NGINX Site Management

Best Practices for Managing Sites with NGINX and Apache

1. One Configuration File Per Site

Always create a dedicated configuration file for each domain or subdomain in the sites-available directory. Mixing multiple sites into a single file creates maintenance headaches and makes troubleshooting significantly harder.

2. Always Test Before Reloading

Make it a non-negotiable habit to run apachectl configtest or nginx -t before every reload. A syntax error in a configuration file can bring down all sites on the server — not just the one you're editing.

3. Use Version Control for Configuration Files

For servers hosting multiple sites or complex configurations, track your configuration files with Git:

cd /etc/nginx/sites-available/
git init
git add .
git commit -m "Initial configuration snapshot"

This gives you a complete change history and the ability to roll back to a known-good state instantly.

4. Always Enforce HTTPS with SSL Certificates

Serving sites over plain HTTP is no longer acceptable. Configure SSL Certificates for every site you manage. Let's Encrypt provides free, auto-renewing certificates and integrates seamlessly with both Apache (via mod_ssl and Certbot) and NGINX.

After obtaining a certificate, update your server block or virtual host to listen on port 443 and redirect all HTTP traffic to HTTPS.

5. Configure Comprehensive Logging

Always define both access_log and error_log directives for each site. Logs are your first line of defense when diagnosing issues, investigating security incidents, or analyzing traffic patterns. Store logs in site-specific files rather than relying on the default global log.

6. Use Descriptive, Consistent File Naming

Name your configuration files after the domain they serve (e.g., example.com.conf for Apache, example.com for NGINX). This makes it immediately obvious which file corresponds to which site when managing a server with many virtual hosts.

Choosing the Right Hosting Environment

The configuration techniques covered in this guide apply regardless of your hosting setup, but your choice of server environment significantly impacts performance and flexibility.

• Shared Web Hosting — Ideal for beginners or small sites where the server configuration is managed for you. NGINX or Apache is pre-configured, and you interact with sites through a control panel.
• VPS Hosting — The sweet spot for developers and system administrators who need full root access to configure NGINX or Apache exactly as described in this guide. You have complete control over sites-available, sites-enabled, and every other aspect of the server.
• Dedicated Servers — Best for high-traffic websites or applications requiring maximum performance and isolation. You manage the entire server, including web server configuration, with no resource sharing.
• VPS with cPanel — Combines the power of a VPS with a graphical control panel, making virtual host management accessible without deep command-line expertise.

Conclusion

The sites-available and sites-enabled directory structure is one of the most practical and elegant patterns in Linux web server administration. It gives system administrators the ability to manage dozens of websites on a single server with precision — enabling, disabling, and modifying sites without ever risking the loss of a configuration.

To summarize the key takeaways:

• sites-available stores all configuration files; sites-enabled contains only the active symlinks.
• Apache uses a2ensite and a2dissite for streamlined site management.
• NGINX relies on manual symlink creation and removal via ln -s and rm.
• Always test your configuration (apachectl configtest or nginx -t) before reloading.
• Reload — don't restart — to apply changes without dropping live connections.
• Enforce HTTPS on every site using SSL Certificates.

Whether you're managing a personal project or a fleet of production websites, these fundamentals will serve as the foundation of a stable, well-organized web server environment. If you're looking for a reliable platform to put these skills into practice, explore AlexHost's VPS Hosting plans — purpose-built for developers and administrators who demand full control over their server environment.