Engineering Glossary · Filesystem
The Document Root Is Your Deploy Target and Your Security Boundary
You are wiring up a deployment and you need to know exactly which directory the web server will serve, and what must stay above it.
The short answer
The document root is the directory a hostname resolves URLs inside, which makes it two things at once: the target every deployment has to land in, and the line between files the public can request and files it cannot.
Modern frameworks make the second point sharper. Laravel, Symfony and most current PHP applications expect the root to be a public subdirectory, with the application code, the vendor tree and the environment file sitting above it. Point the root at the project directory instead and you have published your configuration to anyone who guesses the filename.
By the HostingFast team · Reviewed 12 August 2026
0
Entries with no jargon left over
100+
Terms, all cross-linked
Real
Worked examples, not diagrams
Free
To read, permanently
The main domain normally roots at public_html, while each addon domain and each subdomain is given a root of its own. The mapping is literal: a file at root/blog/post.html answers at your-domain followed by /blog/post.html, and nothing more clever than that is happening.
Nothing above the root is reachable over the web, which is what makes above the root the correct home for credentials, backup archives, deployment artefacts and anything else the internet has no business downloading.
Framework layouts and the public subdirectory
A framework that ships a public directory is telling you where the root belongs. The front controller, the compiled assets and nothing else live there; the application code, the dependency tree and the environment file live one level up where no request can reach them.
If your host lets you set the root per domain, set it to the public directory and stop there. The alternative pattern — rewriting requests from public_html into a subdirectory — works, but it leaves the real project files inside the web root where a misconfigured rewrite exposes them.
Atomic deployments with a symlinked root
The tidy deployment pattern is a releases directory holding timestamped builds and a current symlink that the document root points at. Deploying means building the new release beside the old one and repointing the symlink, which makes the switch instantaneous and the rollback equally so.
One caveat worth knowing before you adopt it: opcode caches key on file paths, so a new release directory means a cold cache for the first requests after each deploy. That is normally a fair trade for an atomic switch, but it is worth expecting rather than discovering.
What belongs above the root, without exception
Environment files, database credentials, private keys, backup archives, deployment logs, uploaded material not yet published, and any script written for an operator rather than a visitor. The test is simple: if a stranger downloading it would ruin your week, it does not belong beneath the root.
Backups are the most common offender. An archive of the whole site sitting inside the web root is one lucky guess away from being somebody else's copy of your database.
Setting the root on this platform
Each domain, addon domain and subdomain on the account carries its own document root, visible and editable in the panel, so a framework layout is a configuration choice rather than a rewriting exercise.
SSH, Git and Composer are available on the developer-focused plans, which is what makes the symlinked-release pattern practical here rather than theoretical. Staging environments let you rehearse the whole sequence before it touches production.
Written for people who deploy, not just upload
A reference aimed at someone with a terminal open reads differently from one aimed at someone with a file manager open. This one assumes the terminal.
SSH, Git and Composer are available on the developer-focused plans, so a deployment can be a command rather than a drag-and-drop.
- 100+ entries written for a terminal
- Framework layouts handled explicitly
- Wired into FTP, Addon Domain and .htaccess
- Written by the engineers who run deploys
Why HostingFast
Standard on every plan
Two jobs, both named
Deploy target and security boundary, treated as the single decision they really are.
Document Root, for frameworks
Where the root belongs when an application ships a public directory, and why.
Atomic deploys explained
The symlinked-release pattern, with the opcode cache caveat stated up front.
An unambiguous rule
If a stranger downloading it would ruin your week, it lives above the root.
Per-domain roots
Each hostname on the account has its own, which is what makes clean layouts possible.
Continues into its neighbours
FTP, Addon Domain and Subdomain follow from here.
Quick Start
From order to online
- 1
Find the root for each hostname
The panel records one per domain. Check the value rather than assuming every hostname roots at public_html.
- 2
Point it at the public directory
For a modern framework, set the root to the application's public folder and leave the rest of the project above it.
- 3
Move secrets above the line
Environment files, keys and backups belong outside the served directory. Verify by requesting one over HTTPS and confirming it is not returned.
- 4
Adopt a symlinked release layout
Build each release beside the last and repoint the symlink. Rollback becomes a second symlink change rather than a restore.
Built In
Loaded onto every plan
- Per-domain document root configuration in the panel
- SSH, Git and Composer on developer-focused plans
- Staging environments for rehearsing a deployment
- Per-site PHP version and extension switching
- NVMe SSD storage on every tier
- Daily backups with self-service restores
- Free engineer-run migration of an existing site
- In-place plan upgrades with no migration
Frequently Asked
What people ask us most often
Where should the document root point for a Laravel or Symfony application?
At the application's public directory, with the code, the vendor tree and the environment file one level above it. Set it per domain in the panel rather than rewriting requests from public_html into a subfolder — the rewrite works, but it leaves your project files inside the web root where a broken rule can expose them.
Can I deploy atomically with symlinks on shared hosting?
Yes, wherever you have SSH. Keep timestamped releases in a directory above the root, point the document root at a current symlink, and repoint it when a build is ready. Expect a cold opcode cache on the first requests after each switch, because the file paths change with every release.
I uploaded a file and the site will not serve it. What went wrong?
It landed outside that hostname's document root, or inside a different domain's root on the same account. Check which path the panel records for that specific domain — they are not all public_html — and place the file beneath it.
Is there a safe place to rehearse a deployment?
Yes — plans with staging clone the live site so you can run the whole sequence on the copy, confirm the root, the permissions and the build all behave, and only then repeat it in production.
Keep reading
Subdomain
Named branches of your domain, each with a root and a certificate of its own.
Addon Domain
A second site in the same account, with its own root and its own deployment.
How to Test Your Website Speed
Getting a real speed figure instead of a feeling, with the tools named.
Web Hosting
cPanel hosting on NVMe with LiteSpeed, free SSL and a migration included.
Mail Filtering
Spam and virus filtering placed in front of any mailbox, hosted anywhere.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Deploy into a root you chose.
Every plan carries the things other hosts bill as extras, plus support that answers when you need it.
View Web Hosting plans