Apache Virtual Host Generator

ServerName:

Use the canonical bare host, for example example.com or app.example.com.

www alias:

Leave on for common public sites that answer both apex and www hostnames.

ServerAdmin:

Use a monitored mailbox or team alias.

Site mode:

Static/PHP modes use DocumentRoot; reverse proxy mode emits ProxyPass directives.

DocumentRoot:

Point at the public web root, not the whole application repository.

Backend URL:

Use a trailing slash for a root proxy, for example http://127.0.0.1:3000/.

PHP-FPM socket:

Common Debian path: /run/php/php8.3-fpm.sock.

TLS plan:

Use redirect plus HTTPS after DNS and certificates are ready.

Certificate paths:

Let's Encrypt paths are derived from ServerName; choose custom to enter exact files.

Certificate file:

Use an absolute readable path, for example /etc/ssl/certs/example.com-fullchain.pem.

Private key file:

Use an absolute private-key path readable by the Apache master process.

Access policy:

Public grants normal web access; local-only is useful for staging or loopback fronting.

AllowOverride:

Use None when rules can live in the vhost file; choose FileInfo or All only when the app requires .htaccess.

Log path style:

Debian uses ${APACHE_LOG_DIR}; RHEL-family systems usually use /var/log/httpd.

Custom log directory:

Use an absolute path writable by the Apache service at startup.

Fix these inputs before deployment

{{ error }}

Review before deployment

{{ warning }}

Extra ServerAlias names:

Leave blank unless the vhost should answer additional DNS names.

Bind address:

Keep * for the common name-based virtual-host setup.

HTTP port:

Port 80 is standard for HTTP virtual hosts.

port

HTTPS port:

Port 443 is standard for HTTPS virtual hosts.

port

DirectoryIndex:

Order matters; PHP apps commonly put index.php first.

Directory Options:

Default disables directory indexes while allowing symlinks commonly used by deployments.

LogLevel:

Use warn for production; temporarily raise during focused troubleshooting.

HSTS policy:

Off is safest until the certificate and every hostname are confirmed live over HTTPS.

Include comments:

Turn off when you need a terse production config.

{{ result.configText }}

Directive	Value	Deployment note	Copy
{{ row.directive }}	{{ row.value }}	{{ row.note }}

Step	Command or check	Reason	Copy
{{ row.step }}	`{{ row.command }}`	{{ row.reason }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Many Apache deployments put several sites behind the same listener instead of dedicating one server or one IP address to each hostname. Virtual hosts make that possible by pairing an address and port with a set of names, content rules, TLS directives, and logs. The arrangement is efficient, but it also means a small vhost change can affect another site when wildcard names, port choices, or file ordering overlap.

DNS only gets the client to the Apache host. After the connection arrives, Apache first narrows the match by the real destination address and port, then compares the request name with the ServerName and ServerAlias values in that address set. That two-stage decision explains why a correct-looking hostname may still miss its site when the vhost is on the wrong port, when another file is loaded first, or when a broad alias catches the request earlier.

Address set: The IP address and port listed in <VirtualHost>. Apache narrows candidates here before checking names.
Server name: The main hostname for the vhost. It should be explicit because inherited or guessed names can produce surprising matches.
Aliases: Extra hostnames, including optional wildcards, that should land on the same vhost as the main name.
Content handoff: The path from Apache to the actual site content: filesystem files, PHP-FPM, or a reverse-proxied backend.

The content handoff changes the risk profile. A static or front-controller vhost needs a tight public directory and a clear <Directory> authorization rule. A PHP-FPM vhost also needs the correct FastCGI target and Apache proxy modules. A reverse proxy vhost depends on a reachable backend URL, host-header behavior that matches the application, and forwarding headers that do not confuse scheme-sensitive redirects or cookies.

TLS adds another set of decisions because the HTTP listener and HTTPS listener often live in separate vhost blocks. An HTTP-only block can be useful before certificates are issued, but public sites usually need HTTPS. A redirect-plus-HTTPS setup keeps normal visitors on secure URLs, while an HTTPS-only block assumes port 80 is handled elsewhere or intentionally closed. HSTS belongs after certificates, redirects, subdomains, and recovery paths are understood, because browsers can remember the policy long after the vhost file changes.

Broad wildcard aliases can capture traffic meant for another vhost if ordering and DNS are not reviewed together.
A document root that points above the public directory can expose code, environment files, or writable storage.
AllowOverride All gives .htaccess files wide control; keeping rules in the vhost is easier to audit when the app allows it.
Readable certificate and private-key paths matter as much as the directive names; Apache still has to open those files at startup or reload.

How to Use This Tool:

Use the generator as a drafting and review aid. Build the host identity first, choose how Apache will hand off requests, then review the generated directives and activation sequence before saving anything on the server.

Enter ServerName as a bare host such as example.com, not a URL with a scheme or path. Use ServerAdmin for a monitored mailbox or team alias.
Decide which names should answer from the same vhost. Keep www alias on for ordinary apex-and-www sites, and add extra aliases only when DNS and certificate coverage are planned for each name.
Choose Site mode. Static and PHP-FPM sites use DocumentRoot; PHP-FPM also needs a socket or host-and-port target. Reverse proxy mode uses Backend URL and omits the directory block.
Set the TLS plan. For HTTPS, keep the Let's Encrypt path profile when it matches your host, or enter custom certificate and key files when your deployment uses another location.
Open Advanced only for values that differ from the normal defaults, such as a nonstandard bind address, nonstandard ports, RHEL-family log paths, a specific AllowOverride policy, a custom DirectoryIndex, or HSTS.
Read any red error or yellow warning before copying the vhost. Errors replace the generated config with explanatory comments. Warnings identify choices that need review, such as HTTP-only output, wildcard aliases, broad overrides, unusual document roots, or HSTS preload.
Use Directive Ledger to check the important emitted directives, then use Activation Checklist for the save path, module step, apachectl configtest, reload command, DNS or certificate check, and curl -I smoke test.

Interpreting Results:

Apache VHost is the draft configuration text. Directive Ledger explains the major directives, values, required modules, and review notes. Activation Checklist converts the draft into server-side checks. JSON captures the inputs, warnings, errors, generated config, ledger rows, and checklist rows for records or ticket notes.

The summary state is a drafting signal, not a server guarantee. Ready means the visible inputs pass the generator's checks and no warning was raised. Apache can still reject the file because a module is missing, a certificate key cannot be read, a document root does not exist, or a backend service is unreachable.

Apache virtual host result cues and next checks
Cue	What it means	What to do next
`Needs edits`	A required value is missing or invalid, so the real vhost text is withheld.	Fix the alert first. Do not deploy the comment-only output.
`Review`	The draft was generated, but one or more safety warnings were raised.	Compare each warning with the affected ledger row and the target host plan.
`Ready`	The draft passed known local checks and did not trigger warnings.	Run the activation checklist on the actual server before reload.
`Required modules`	The module row reflects choices such as TLS, redirect, headers, PHP-FPM, and proxying.	Enable or verify those modules before `apachectl configtest`.
Alias count	The summary includes aliases that will be emitted in `ServerAlias`.	Repeat DNS, certificate, and smoke checks for each public name.

Generated size and counts are useful change markers, but they do not prove correctness. The strongest confidence comes from reviewing the directives, running a syntax test, reloading cleanly, and confirming that every expected hostname reaches the intended content over the intended scheme.

Technical Details:

Apache virtual host matching is ordered around the connection target. The server first chooses the most specific matching address and port from the available <VirtualHost> blocks. Name comparison happens only among vhosts in that winning address set, and the port text inside the HTTP Host header does not replace the real destination port. For TLS, Server Name Indication can supply the requested name during the handshake so Apache can select the right certificate-bearing vhost.

Within the selected address set, ServerName and ServerAlias are compared against the request name. If no name matches, the first vhost for that address and port becomes the fallback. That fallback rule makes ordering important whenever a wildcard alias, broad bind address, or missing name could overlap another host.

Rule Core:

Apache virtual host rule core
Rule area	Mechanism	Review consequence
Address and port	`<VirtualHost address:port>` controls the first candidate set.	A vhost on the wrong port can never answer the expected request, even if the name is correct.
Listener boundary	`<VirtualHost>` selection does not open sockets by itself; Apache must also listen on the intended address and port.	Check the server's listener configuration when a valid vhost never receives traffic.
Name match	`ServerName` and `ServerAlias` decide among tied address candidates.	Aliases should match real DNS names and certificate names, not just desired shortcuts.
Fallback	The first vhost in an address set handles requests with no matching name.	Default-vhost ordering should be intentional before adding wildcards or new hosts.
Directory access	`Require`, `Options`, and `AllowOverride` shape filesystem serving.	Grant only the access and override surface the application needs.
Proxy and PHP-FPM	Apache hands matching requests to a backend or FastCGI handler through proxy modules.	Module availability and backend reachability must be checked outside the draft text.

The generated patterns follow ordinary Apache deployment shapes. TLS choices alter the number of vhost blocks, content mode changes the handoff directives, and log family changes the path convention without changing request matching.

Generated Apache virtual host patterns
Selection	Emitted pattern	Boundary to verify
HTTP vhost only	One content vhost on the HTTP port.	Appropriate for local or pre-certificate work; public launch usually needs HTTPS.
HTTP redirect plus HTTPS	One redirect vhost and one HTTPS content vhost.	The certificate must cover the main name and any public aliases.
HTTPS vhost only	One content vhost on the HTTPS port.	Port 80 should be handled elsewhere or deliberately unavailable.
Static or front-controller site	`DocumentRoot`, `DirectoryIndex`, `Options`, `AllowOverride`, and `Require`.	The root should point at a public directory, not the whole project tree.
PHP-FPM site	Document-root directives plus a PHP `SetHandler`.	The socket or host-and-port value must match the running PHP-FPM pool.
Reverse proxy site	`ProxyPreserveHost`, forwarded scheme header, `ProxyPass`, and `ProxyPassReverse`.	The backend must be reachable from Apache and must expect the forwarded host and scheme.

Apache module conditions for generated vhost directives
Generated feature	Modules to check	Reason
HTTPS vhost	`ssl`	Provides `SSLEngine`, certificate file, and private-key directives.
HTTP-to-HTTPS redirect	`alias`	Provides the redirect directive used in the HTTP block.
HSTS or reverse proxy	`headers`	Sets response or upstream request headers.
Reverse proxy	`proxy`, `proxy_http`	Forwards HTTP requests to the backend URL.
PHP-FPM	`proxy`, `proxy_fcgi`, `setenvif`	Passes PHP requests to FastCGI through Apache's proxy handler.

This is a rule-based configuration generator rather than a numeric calculator, so there is no formula core. The governing mechanism is directive selection: validated host identity plus content mode plus TLS plan plus review policies determine the vhost blocks, supporting directives, warning state, module list, and activation checks.

Limitations, Privacy, and Deployment Notes:

The generator builds the draft in the browser and does not test your Apache host, read your filesystem, contact your backend, query DNS, open Apache listeners, or validate certificate coverage. Copying and downloading use the values visible on the page, so review hostnames, paths, email addresses, and backend URLs before sharing exported files.

Configuration syntax is necessary but not enough. A passing apachectl configtest proves Apache can parse the file with the currently loaded modules. It does not prove that the document root contains the right release, the app responds correctly, DNS points to this server, the certificate chain is trusted, or all aliases resolve to the intended place.

Be conservative with settings that persist outside the file. HSTS can be remembered by browsers, wildcard aliases can route broad traffic, and .htaccess overrides can move security-sensitive behavior out of the vhost. Record why those choices are needed when they are enabled.

Worked Examples:

For a static site moving to HTTPS, enter example.org, keep the www alias if both names should work, set DocumentRoot to /var/www/example.org/public, and choose the redirect-plus-HTTPS plan with Let's Encrypt paths. The vhost draft should contain an HTTP redirect block, an HTTPS content block, certificate directives, per-vhost logs, and a module list that includes ssl and alias.

For a PHP-FPM application, use a public document root such as /srv/app/current/public and a socket such as /run/php/php8.3-fpm.sock. If the app requires rewrite rules in .htaccess, FileInfo is narrower than All. The ledger should include the PHP handler target and the proxy/FastCGI modules to verify before configtest.

For a reverse proxy, enter a full backend URL with an HTTP or HTTPS scheme, host, port when needed, and trailing slash. A value like localhost:3000 is rejected because the scheme is missing. After the draft is generated, check that the upstream app expects the original host header and the forwarded scheme used by Apache.

FAQ:

Can I deploy the generated vhost unchanged?

Deploy it only after server-side checks pass. Review the directives, save it in the correct include path, enable required modules, run apachectl configtest, reload Apache, and smoke test the expected hostnames.

Why does the vhost sometimes output only comments?

That happens when required inputs fail validation. Common causes include an invalid ServerName, an unmonitored-looking ServerAdmin, a reverse-proxy backend without an HTTP or HTTPS scheme, or missing custom certificate paths.

When should I keep AllowOverride None?

Use None when rewrite, access, and header behavior can live in the vhost or main config. It avoids extra filesystem checks and keeps security-sensitive behavior in one reviewed file.

Why does reverse proxy mode preserve the Host header?

Many applications use the incoming host to build redirects, absolute links, tenant routing, or cookie domains. Preserving the host keeps the backend aligned with the public hostname, but the app must be configured to trust the proxy setup correctly.

What makes HSTS preload risky?

Preload scope is hard to undo because browsers can enforce HTTPS before contacting the site. Use it only after every relevant subdomain works over HTTPS and the domain is ready for long-lived browser enforcement.

Glossary:

VirtualHost: An Apache configuration block tied to an address and port, and usually to one or more hostnames.
ServerName: The primary hostname Apache compares against the request name when choosing a name-based vhost.
ServerAlias: Additional hostname patterns that can route to the same vhost as the primary name.
DocumentRoot: The filesystem directory Apache serves for static files or front-controller requests.
PHP-FPM: PHP FastCGI Process Manager, commonly reached from Apache through a Unix socket or host-and-port target.
Reverse proxy: A setup where Apache accepts the public request and forwards it to another HTTP application server.
HSTS: HTTP Strict Transport Security, a response header that tells browsers to use HTTPS for future requests to a host.

References:

How to create a virtual host in Apache, Simplified Guide.
How to redirect HTTP to HTTPS in Apache, Simplified Guide.
How to configure Apache as a reverse proxy, Simplified Guide.
Apache name-based virtual host documentation, Apache HTTP Server Version 2.4.
Apache virtual host matching details, Apache HTTP Server Version 2.4.
Apache AllowOverride directive, Apache HTTP Server Version 2.4.
Apache mod_ssl documentation, Apache HTTP Server Version 2.4.
Apache mod_proxy documentation, Apache HTTP Server Version 2.4.
Apache mod_proxy_fcgi documentation, Apache HTTP Server Version 2.4.
Strict-Transport-Security header reference, MDN Web Docs.