Direct sites
A direct site is served straight from its files: your application is the website's document root, PHP scripts, HTML, and assets, run in place by the web server with no proxy in between.
There's no process to create and no separate panel page: a
Website service plus files under
public/<domain> is the application. WordPress and most standard PHP
software work this way. Hosting architectures
compares the three.
Two things set a direct site apart from an app server and a container:
- Nothing runs between requests. The web server runs your code one page at a time: no process to start, no idle shutdown, no start delay. A direct site also needs no persistent services, so it works on every account.
- The code runs as the web user, not as you. See below.
Where the files go
Each website's document root defaults to public/<domain> in your home
directory, e.g. public/www.example.com. You can point it somewhere else
from the website service, or with Set as Web Root in the file manager.
Put your files there however you like: the
file manager, SFTP, SSH, the browser terminal,
or the code editor. An index.php or index.html in the document root is
the entry point. Put a website online
walks from a bare domain to a live site.
If the application needs a database, create one under Databases and put its credentials in the app's configuration file. For software you upload and open in the browser, that's usually the whole installation.
Once the files are in place, the panel recognizes WordPress, Drupal, and others, and lists them under Applications and updates, which tells you when a new version exists and can apply it for you.
Who runs the code: the web user
A direct site runs as your -www companion user, not as your login
user. Web-facing PHP is the most exposed code you run, so a plugin an
attacker takes over can only touch what you granted to the web user.
The user security model has the full reasoning.
The practical result is web permissions. Your files are private by default; you grant the web server access to each file or folder with the Web Permission action in the file manager:
| Grant | Use it for |
|---|---|
| Read, Execute | The document root, and anything the application reads. |
| Read, Write | A directory the application writes to: an upload folder, a cache, or wp-content/uploads. |
A page that returns "forbidden" for no obvious reason is almost always a missing web permission. Check that first, in the file manager.
PHP versions and settings
You select PHP per directory. A handler line in the directory's
.htaccess pins the version for that site, and for php on the command
line there:
AddHandler php83 .php
Without it, the server's default version applies. PHP
covers that line, the .ini files that hold your settings, and the
phpinfo output.
.htaccess also works as usual for URL rewrites (clean permalinks),
headers, and access rules.
TLS is the one thing you never set up. The panel handles certificates and HTTPS for you.
Maintenance from the command line
Some commands belong to the application: a CMS upgrade, a cache rebuild,
anything that writes the files the web app also writes. Run them as the
web user, with wsudo:
wsudo wp core update --path=~/public/example.com
Run such a command as your login user and you own the files it creates, so the web app can no longer overwrite them.
The same goes for the app's cron jobs: put
wsudo in front of the command. For WordPress, WP-CLI is already
installed. See Runtimes & Tools.
When something misbehaves, PHP errors and refused requests are in the website's access and error logs. See Logs.
Mixing the architectures
A direct site works alongside the other architectures on one website: the
document root serves /, and a mount can attach an app
server at /api or a container service at /search. The most specific
path wins, so the direct site keeps serving everything you didn't mount
over.
Software that wants a continuously running process, or comes as a container image, no longer fits in a document root. Then move to an app server or a container.