Build Apache Virtual Hosts Faster with Bash (Part 28 / 34)

×

You've got three projects to spin up today, and the first thing you do is open /etc/apache2/sites-available/ and start typing another virtual host config from scratch. Again.

If you manage Apache on Ubuntu or Debian-based systems and find yourself creating virtual hosts more than once a week, this is for you. After working through this, you will have a script that creates the vhost config, enables the site, updates your hosts file, sets up the document root, and restarts Apache all from a single command.

If you're newer to shell scripting and want a solid foundation before diving into automation scripts, the introduction to bash scripting on LinuxTeck is worth reading first. It covers the basics you'll see throughout this article.

Before writing any code, it helps to know exactly what steps you're replacing. Creating an Apache virtual host manually on Ubuntu or Debian involves all of this:

• Creating the document root directory under /var/www/
• Writing a .conf file inside /etc/apache2/sites-available/
• Running a2ensite to enable it
• Adding a line to /etc/hosts for local DNS resolution
• Restarting or reloading Apache

That's five steps. When you do it ten times a week across different projects, it adds up fast. And if one person on your team does it slightly differently say, they forget a2ensite or set the wrong permissions on the document root you end up debugging things that should never need debugging.

The script we're building handles all five steps. You pass it a domain name. It does the rest.

Every bash script starts with this:

That first line tells your system which interpreter to use when you execute the file. Without it, the shell uses whatever the current default is and on some systems, that's sh, not bash. The sh shell doesn't support all bash features like [[ conditionals, certain string operations, or local variables inside functions. Scripts that work fine when you run bash script.sh directly can break silently when you run ./script.sh without the shebang.

Always include it. Always use the full path /bin/bash. Never assume.

After you create the script file, it won't run until you give it execute permission. This is the step that trips up beginners more than almost anything else.

The x bit in rwx means the file is executable. Without it, you get a "Permission denied" error even though you own the file. The chmod +x command adds execute permission for the owner, group, and others. If you only want the owner to run it, use chmod u+x instead that's the safer choice for scripts that touch system files.

This script needs sudo because it writes to /etc/hosts and /etc/apache2/sites-available/. Both of those paths are root-owned. Run it like this:

Here's the complete script. Walk through each section below every block has a reason for being exactly where it is.

The configuration block at the top defines every path as a variable. This is intentional. If Apache is installed in a non-standard location, or you're adapting this for a staging server with different paths, you change three lines at the top not ten lines scattered through the script.

Right after the empty-domain check, the script runs a format validation using a regex pattern. It rejects anything that contains spaces, slashes, quotes, or other characters that don't belong in a hostname. If someone passes in my project/local by accident or types something with a trailing slash, the script exits cleanly before it has a chance to build a broken path and write it to a system file. Small input errors without this check can turn into very confusing file permission issues later.

Now the document root creation block:

The chown -R www-data:www-data line matters. Apache runs as the www-data user on Ubuntu. If your document root is owned by root, Apache can read files but cannot write them. That means no uploads, no cache files, no writable logs in that directory. The chown is not optional.

Now the vhost config block this is the part that writes the actual Apache configuration file:

The Options -Indexes line in the directory block is a security measure. Without it, if your document root has no index file, Apache displays a file listing of everything in that directory. That's fine in development but a genuine risk in any environment where the wrong person can reach it. The script includes it by default.

For a local development domain to resolve in your browser, it needs an entry in /etc/hosts. This is the step that trips up the most people they create the vhost, enable it, reload Apache, open the browser, and get a DNS error because the hosts file was never touched.

The grep -qw check before appending to the hosts file is important. The -w flag matches whole words only, not substrings. Without it, grep -q "project.local" would match a line containing myproject.local and incorrectly skip adding your new domain. The -q flag suppresses output and uses the exit code only. Together, -qw gives you an exact, silent hostname match the right tool for this check.

Also notice the apache2ctl configtest before the reload. It validates the Apache config syntax before reloading. If the heredoc had an error (say, a variable that expanded to something unexpected), the reload would fail. Running configtest first means you catch that before Apache tries to load a broken config.

Scripts fail. When this one does, here's how to find out why quickly.

The first tool to reach for is bash -x. It prints every command the script executes, with variable values expanded, before running it. Run it like this:

Every line starting with + is a command that executed. You can see exactly what each variable expanded to. If something is wrong a path is empty, a variable didn't expand, a condition evaluated the wrong way it shows up immediately.

If your script exits early and you're not sure where, add set -e and set -x at the top right after the shebang. set -e exits immediately on any command that returns a non-zero exit code. Combined with -x, you see the exact line the script stopped on.

One important caveat if you add set -e to this script: commands used as conditions inside an if statement are exempt from set -e. Bash handles their exit code through the if construct itself, so grep returning 1 (no match) is treated as a false condition rather than a crash-worthy error. That means the grep -qw check works correctly under strict mode with no extra logic needed:

No extra logic is needed here. Bash does not trigger set -e on commands used as the condition inside an if statement the if construct handles the exit code itself, so grep returning 1 (no match found) is treated as a false condition, not a script-crashing error. The pattern above works correctly under strict mode without any || true workaround.

Where set -e does cause unexpected exits is with standalone commands outside an if for example, grep -q "pattern" file on its own line will crash the script if there is no match. In those cases, grep -q "pattern" file || true is the right guard. But inside an if condition, you never need it. For a full breakdown of how exit codes flow through scripts, the bash exit codes and error handling guide on LinuxTeck is worth the read.

Once you have this working, the mental shift is more useful than the script itself. You start seeing every repetitive admin task as something scriptable. Setting up a new project means running one command instead of remembering a five-step checklist. Onboarding a new developer means handing them a script instead of writing instructions they'll follow imperfectly.

This same pattern collect input, validate, create files, update config, restart service applies to a lot of server tasks. Adding an nginx server block works the same way. Provisioning a new database and user follows the same structure. Even something like setting up SSH keys for a new user is three or four commands you can wrap in a script and run in five seconds.

The version of this script above is solid for local development. For a staging or production environment, you'd want to extend it. Input validation to reject domains with spaces or special characters. A cleanup function that removes the vhost, disables the site, and clears the hosts entry when you tear down a project. SSL integration using Certbot for a2enmod ssl. Maybe a --dry-run flag that prints what it would do without actually doing it. None of that is complicated once you have the structure. It's just adding blocks to something that already works.

You can also take this further with cron jobs for tasks like certificate renewal checks, or scheduled log rotation per virtual host. Scripting and scheduling work well together, and once you're comfortable with one, the other comes naturally. The official GNU Bash manual is the best reference when you're extending scripts and need to understand edge cases around parameter expansion or conditional expressions.

Now that you have this working, spinning up a new local development site takes one command and about three seconds. The bash script to create Apache virtual hosts you built here handles every step that used to require opening multiple files and remembering a specific sequence: document root creation, permissions, vhost config, a2ensite, hosts file, and Apache reload. Get one step wrong manually and you're debugging for ten minutes. Let the script do it and you get a consistent result every time.

The next thing worth learning after this is how to add SSL to these local vhosts using mkcert or self-signed certificates. After that, wrapping this script in a fuller project provisioner that also sets up a database and maybe a basic PHP or Node environment. Small scripts compound quickly.

For more on writing reliable shell scripts that handle errors properly, the bash exit codes and error handling guide is the logical next read.

Related Articles

• What Is Bash Scripting in Linux (Part 1 of 34)
• Bash Script Exit Codes and Error Handling (Part 5 of 34)
• How to Install Apache on Rocky Linux
• Secure Apache with SSL in Rocky Linux
• Linux Bash Scripting Automation 2026