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.

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.

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.

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 }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Apache virtual hosts let one web server answer different hostnames with different configuration blocks. In a name-based setup, the request arrives on an address and port, then Apache compares the requested host against the configured ServerName and ServerAlias values. That matching step decides whether the request is served from a document root, handed to PHP-FPM, or proxied to an application server.

A virtual-host file is usually small, but a small mistake can route the wrong site, expose the wrong directory, or reload Apache with a missing module. The important details are not only the hostname and path. Ports, aliases, certificate files, access rules, log locations, and redirect behavior all have to agree with DNS, the certificate, loaded modules, and the server family.

Name-based Apache virtual host selection from host header to matching vhost and content handoff.

The safest way to read any generated vhost is as a deployment draft, not as proof that the server is ready. Apache still has to load the required modules, read the chosen files, pass a syntax test, and answer the expected hosts after reload. A clean-looking file can still fail if the certificate path is wrong, the backend app is down, the document root exposes too much, or a wildcard alias catches traffic meant for another site.

Good virtual-host drafting therefore separates three questions. Which hostnames should match this block? Which content handoff should Apache use? Which activation checks prove that the live server, DNS, and certificate match the draft?

Technical Details:

Name-based virtual hosting begins with the local address and port in the <VirtualHost> argument. After Apache finds the best address and port set, it compares the request host with ServerName and any ServerAlias values in that set. If no name matches, the first matching vhost for that address and port can become the fallback, which is why ordering and explicit hostnames matter.

The generated draft follows that model. It writes one content vhost for HTTP or HTTPS-only plans, or two blocks when the plan redirects HTTP to HTTPS. The redirect block keeps host matching and logs, then sends traffic to the canonical HTTPS host. The content block either serves files from a DocumentRoot, adds a PHP-FPM SetHandler, or emits reverse-proxy directives for an upstream URL.

Rule Core

request address:port -> matching <VirtualHost> set -> ServerName or ServerAlias comparison

matched vhost -> DocumentRoot, PHP-FPM handler, or reverse proxy backend

TLS plan -> certificate directives, optional redirect vhost, optional HSTS header

Apache virtual host directive families and review checks
Directive family	What it controls	What to verify before reload
`ServerName` and `ServerAlias`	Host matching inside the chosen address and port set.	Every listed hostname must resolve to this Apache host, and wildcard aliases should not mask another vhost.
`DocumentRoot` and `<Directory>`	Static file serving, index order, directory options, override policy, and `Require` access rule.	The path should point at a public web root, not a full application repository or private parent folder.
`SetHandler`	PHP requests are sent to a PHP-FPM Unix socket or host and port target through FastCGI proxy handling.	The PHP-FPM service, socket permissions, and proxy FastCGI module must match the emitted target.
`ProxyPass` and `ProxyPassReverse`	Requests are forwarded to an upstream app, and backend redirects are rewritten for the public host.	The backend URL should include the intended trailing slash behavior and be reachable from the Apache server.
`SSLCertificateFile` and `SSLCertificateKeyFile`	HTTPS vhosts point at the certificate chain and private key that Apache reads at startup.	The certificate must cover the served hostnames, and the key file should have restricted permissions.
`Strict-Transport-Security`	HTTPS responses can tell browsers to use HTTPS for future requests, with optional subdomain and preload scope.	Only keep subdomain or preload policy after every affected hostname is ready for HTTPS.
`ErrorLog`, `CustomLog`, and `LogLevel`	Per-vhost logging and verbosity for reload review and incident triage.	Use the correct Debian-family, RHEL-family, or custom log directory for the target host.

The source validation is intentionally narrow. Hostnames are normalized and checked, extra aliases may include wildcards, reverse-proxy mode requires an http:// or https:// backend URL, custom TLS mode requires both certificate paths, and ServerAdmin must look like an email address. Port controls accept values from 1 through 65535 and fall back to standard ports when a value is outside that range.

Generated warning themes in the Apache vhost generator
Warning theme	Why it appears	Practical response
HTTP-only output	`TLS plan` is set to HTTP vhost only.	Use it for local or pre-certificate setup, then move public sites to HTTPS when DNS and certificates are ready.
`AllowOverride All`	Directory overrides are broad for a document-root site.	Prefer `None` or `FileInfo` unless the app really needs wider `.htaccess` control.
Unusual `DocumentRoot`	The path does not end in a common public directory name such as `public`, `htdocs`, `html`, `webroot`, or `www`.	Confirm private code, environment files, and writable storage are not exposed by the served root.
Wildcard alias	An extra alias begins with `*.`.	Check DNS and default-vhost ordering so broad aliases do not steal another host's traffic.
HSTS preload	The HTTPS block emits `max-age=31536000; includeSubDomains; preload`.	Keep it only after the whole domain family is ready for long-lived HTTPS behavior.

The required-module list is derived from selected directives. TLS adds ssl, HTTP-to-HTTPS redirect adds alias, HSTS and reverse proxy use headers, reverse proxy uses proxy and proxy_http, and PHP-FPM uses proxy, proxy_fcgi, and setenvif. The list helps prepare the host, but apachectl configtest is still the authority before reload.

Everyday Use & Decision Guide:

Start with ServerName, ServerAdmin, and Site mode. Those three fields decide the identity of the vhost, the operations contact written into the file, and whether the content block is static files, PHP-FPM, or reverse proxy. Leave the www alias on only when that hostname should answer the same site.

Choose the TLS plan based on what is ready now. HTTP vhost only is useful for a temporary local or pre-certificate draft. HTTP redirect plus HTTPS vhost is the common public shape after DNS and certificates are in place. HTTPS vhost only fits servers where port 80 is handled elsewhere or intentionally closed.

Use Advanced when the default assumptions do not match the target host. Bind address, ports, log path style, DirectoryIndex, Directory Options, LogLevel, HSTS policy, and extra aliases can change how the same vhost behaves after reload.

For a static or PHP app, check DocumentRoot first. It should usually end at a public directory, not at the project root.
For PHP-FPM, check the PHP-FPM socket format before trusting the generated SetHandler.
For a reverse proxy, check the Backend URL and trailing slash because that value feeds both proxy directives.
For HTTPS, check the certificate profile. The Let's Encrypt path is derived from ServerName; custom mode needs exact certificate and key files.

Stop when Fix these inputs before deployment appears, because the vhost text is replaced with comments until errors are cleared. Treat Review before deployment as a real pause too. The draft may still be useful, but the warnings point at choices that deserve a second look before copying the Apache text into a host.

Step-by-Step Guide:

Use the result panels as a drafting and review path, then test the file on the target server.

Enter ServerName and ServerAdmin. The summary should show the hostname instead of Needs edits; if it does not, clear the message under Fix these inputs before deployment.
Set www alias and any Extra ServerAlias names. Open Directive Ledger and confirm the ServerAlias row contains only hostnames this vhost should answer.
Choose Site mode. For static files, review DocumentRoot; for PHP-FPM, review both DocumentRoot and PHP-FPM socket; for reverse proxy, review Backend URL and expect ProxyPass in Directive Ledger.
Choose TLS plan. If HTTPS is enabled, set Certificate paths and HSTS policy, then confirm Apache VHost contains certificate directives and, when selected, a Strict-Transport-Security header.
Open Advanced and adjust bind address, ports, log path style, AllowOverride, access policy, and log level only when the target host needs those changes.
Read the alert area. Fix invalid hostnames, backend URLs, email addresses, or missing custom certificate paths before using the generated text.
Open Activation Checklist. Use the save path, module command, apachectl configtest, reload command, DNS or certificate check, and curl -I smoke test as the deployment review sequence.
After the server passes syntax and smoke tests, repeat the check for aliases and any HTTPS hostnames covered by the same vhost.

Interpreting Results:

Apache VHost is the deployable draft text. Directive Ledger explains the important emitted directives and the selected required modules. Activation Checklist turns the draft into a review sequence for saving, enabling, syntax testing, reloading, and checking DNS or TLS.

The summary badge is a drafting signal, not a server result. Ready means the page did not find the errors or warnings it knows how to detect. It does not mean Apache has the modules loaded, the paths exist, the private key is readable, DNS points at this host, or the backend app is healthy.

How to interpret Apache vhost generator output states
Output cue	Meaning	Next check
Needs edits	A required input is invalid or missing, and the config body is replaced by comments.	Clear the alert before using Apache VHost.
Review	The draft was generated, but one or more warnings were flagged.	Read each warning and compare it with the Directive Ledger row it affects.
Ready	Inputs passed the page checks and no review warnings were raised.	Run `apachectl configtest`, reload Apache, then use the DNS, certificate, and smoke checks in Activation Checklist.
Required modules	The module list reflects TLS, redirect, proxy, PHP-FPM, and header choices.	Enable or verify those modules before the syntax test.

Do not overread generated size or alias count. They are useful for spotting a changed draft, but the real confidence comes from directive review, module checks, configtest, reload behavior, and host-specific smoke tests.

Worked Examples:

Static site moving to HTTPS

A site uses ServerName example.org, keeps www alias on, chooses Static files or app front controller, sets DocumentRoot to /var/www/example.org/public, and uses HTTP redirect plus HTTPS vhost with Let's Encrypt paths. Apache VHost should show an HTTP redirect block and an HTTPS content block. Directive Ledger should list the alias, certificate paths, DocumentRoot, logs, and required modules such as ssl and alias. The result is a draft for a normal public site, but Activation Checklist still needs the DNS and certificate checks before reload.

PHP-FPM app with narrow overrides

An app uses ServerName app.example.net, Site mode PHP-FPM application, DocumentRoot /srv/app/current/public, PHP-FPM socket /run/php/php8.3-fpm.sock, AllowOverride FileInfo, and Access policy Require all granted. Directive Ledger should include a SetHandler target and required modules proxy, proxy_fcgi, and setenvif. If Review before deployment appears because the document root does not look public, fix the path before relying on the generated vhost.

Reverse proxy with HSTS caution

A Node app listens at http://127.0.0.1:3000/. Set Site mode to Reverse proxy to app server, enter that Backend URL, choose HTTPS vhost only, and set HSTS to include subdomains only after every subdomain has a working HTTPS route. Apache VHost should contain ProxyPreserveHost, RequestHeader set X-Forwarded-Proto, ProxyPass, and ProxyPassReverse. A preload setting emits max-age=31536000; includeSubDomains; preload and should keep the result in review until the domain owner accepts that long-lived browser behavior.

Troubleshooting a blocked draft

If reverse-proxy mode is selected and Backend URL is entered as localhost:3000, Fix these inputs before deployment should ask for a valid http:// or https:// backend URL. The Apache VHost panel will not produce the real vhost text until the URL is corrected, for example to http://127.0.0.1:3000/. That is the right behavior because an ambiguous backend target would produce a misleading proxy draft.

FAQ:

Can I deploy the generated vhost without changing it?

Only after host-level checks pass. The page can draft the vhost, warnings, directive ledger, and activation checklist, but Apache still needs the right modules, readable paths, valid certificates, DNS, and a passing apachectl configtest.

Why does ServerName matter so much?

Apache uses ServerName and ServerAlias after address and port matching to choose the vhost. A missing or wrong hostname can send traffic to another block that happens to match first.

When should I use reverse proxy mode?

Use it when Apache should front an app server such as http://127.0.0.1:3000/ instead of serving files from DocumentRoot. The result uses proxy directives and lists proxy modules in Directive Ledger.

What does the HSTS preload warning mean?

It means the HTTPS vhost will emit a long-lived HSTS header with subdomain and preload scope. Keep that setting only after the full domain family is ready for HTTPS and you have reviewed the browser policy impact.

Why is the vhost text replaced by comments?

That happens when Fix these inputs before deployment is active. Common causes are an invalid ServerName, invalid ServerAdmin, missing custom certificate path, or reverse-proxy backend URL without an http:// or https:// scheme.

Does the result check my live Apache server?

No. The result is built from the fields in the page. Use Activation Checklist for the external checks that prove the live host, modules, DNS, certificate, reload, and smoke test all match the draft.

Glossary:

VirtualHost: An Apache configuration block that applies to a specific address and port set, then usually to one or more hostnames.
ServerName: The primary hostname Apache compares against the request host when choosing a name-based vhost.
ServerAlias: Additional hostnames or wildcard names that can map to the same vhost as the primary hostname.
DocumentRoot: The filesystem directory Apache serves for static or PHP front-controller requests in a document-root vhost.
PHP-FPM: PHP FastCGI Process Manager, commonly reached from Apache through a Unix socket or host and port target.
Reverse proxy: An Apache setup that forwards incoming requests to an upstream app server and returns the upstream response to the client.
HSTS: HTTP Strict Transport Security, a response header that tells browsers to use HTTPS for future requests to a host.

References:

Name-based Virtual Host Support, Apache HTTP Server Version 2.4.
Apache Module mod_ssl, Apache HTTP Server Version 2.4.
Apache Module mod_proxy, Apache HTTP Server Version 2.4.
Strict-Transport-Security header, MDN Web Docs.