# Administrator access

On a TurboStack host you work as your own **system user**, not as the administrator (`root`). That
is deliberate. The platform manages the server's configuration. A change made by hand outside that
model is overwritten on the next [publish](../platform/hosts/publishing.md), or it quietly breaks
something the platform expects.

Your system user can still do a small number of things with administrator rights. These are the
day-to-day operations that would otherwise need a support ticket: telling a service to re-read its
configuration, or clearing a cache.

> [!WARNING]
> **These commands act on the entire server, not only on your own application.** If several
> applications, or several customers' sites, run on the same host, a reload or a cache clear affects
> all of them. Know what a command does before you run it, and prefer a quiet moment.
>
> If you are not sure, ask [Support](../platform/support.md). That is cheaper than finding out on a
> production host.

## Reload and restart are not the same thing

A **reload** tells a service that is already running to re-read its configuration. It keeps serving
visitors while it does so. This is what you want in almost every case.

A **restart** stops the service and starts it again. Visitors get an error while it is down. You
rarely need one.

## What your system user may run

Put `sudo` in front of the command. It works only for the commands below; anything else is refused.

This list is generated from the platform's own configuration, so it is always what the servers
actually grant:

| Command | What it does | What it affects |
| --- | --- | --- |
| `sudo /bin/systemctl reload php*-fpm.service` | Re-reads PHP settings and a changed [preload script](../technologies/php/configure.md#opcache-preloading). About a tenth of a second, with no downtime. Replace the `*` with your version, for example `php8.4-fpm`. | Every application on that PHP version. |
| `sudo /usr/sbin/service php*-fpm reload` | The same reload, in the older `service` syntax. | Every application on that PHP version. |
| `sudo /bin/systemctl reload nginx.service` | Applies changes you made to the web server includes in `~/nginx/`. | Every site on the host. A broken configuration is refused, so the running server keeps serving. |
| `sudo /usr/sbin/reloadnginx` | The same reload, through a helper script. | Every site on the host. |
| `sudo /usr/sbin/reloadapache2` | Reloads Apache, on hosts that run Apache instead of Nginx. | Every site on the host. |
| `sudo /bin/systemctl reload varnish.service` | Applies a changed Varnish configuration. | Every site behind Varnish on the host. |
| `sudo /usr/sbin/reloadvarnish` | The same reload, through a helper script. | Every site behind Varnish on the host. |
| `sudo /usr/sbin/clearvarnish` | Empties the Varnish full-page cache. Same as `tscli varnish clear`. | Every site behind Varnish. They all start rebuilding their cache at once, so the traffic lands on PHP together. |
| `sudo /usr/sbin/resetopcache` | Clears the PHP OPcache, so changed code is picked up. Same as `tscli opcache clear`. | Every application on the host. Brief slowdown while PHP recompiles. |
| `sudo /usr/local/bin/tscli` | Any [tscli](../api/cli.md) command. You never have to type `sudo` for it - tscli asks for the rights it needs itself. | Depends on the command. |
| `sudo /bin/systemctl restart blackfire-agent*` | Restarts the Blackfire profiler agent. Prefer `tscli blackfire reload`. | Profiling only. Sites keep running. |
| `sudo /usr/sbin/reloadblackfire` | Reloads the Blackfire agent after a credentials change. | Profiling only. |
| `sudo /usr/sbin/enableblackfire` | Installs and starts the Blackfire profiler. | Restarts PHP-FPM, so every application on the host pauses briefly. |
| `sudo /usr/sbin/disableblackfire` | Removes the Blackfire profiler. | Restarts PHP-FPM, so every application on the host pauses briefly. |
| `sudo /bin/systemctl restart tideways-daemon*` | Restarts the Tideways daemon. | Profiling only. Sites keep running. |
| `sudo /usr/sbin/reloadtideways` | Reloads Tideways after a configuration change. | Profiling only. |
| `sudo /usr/sbin/enabletideways` | Switches the Tideways profiler on. | Profiling for the applications you enabled it for. |
| `sudo /usr/sbin/disabletideways` | Switches the Tideways profiler off. | Profiling only. |
| `sudo /bin/systemctl restart newrelic-infra` | Restarts the New Relic infrastructure agent, which reports the server's own metrics. | Monitoring only. Sites keep running. |

> [!NOTE]
> The `*` in a command is a wildcard the rule allows, not something you type literally. Use your own
> version, for example `sudo systemctl reload php8.4-fpm.service`.

## The ones to be careful with

| Command | Why it deserves thought |
| --- | --- |
| `tscli php kill` | Stops **all** PHP on the host, master processes included. The platform restarts it automatically, but PHP is unavailable for roughly 15 to 20 seconds and in-flight requests are lost. Use it only when PHP is genuinely stuck - to apply a change, reload instead. |
| `tscli varnish clear` | Every site behind Varnish loses its full-page cache at once, so all that traffic lands on PHP together. On a busy shop that is a real load spike. |
| `tscli opcache clear` | Harmless, but it slows every application on the host for a moment while PHP recompiles. |

## What is not included

There is no root shell, and no way to install packages, edit system configuration, or restart
databases yourself. Those are the platform's to manage, and doing them by hand would put the server
out of step with its configuration. [Support](../platform/support.md) handles them.

## Related

- [SSH access](../platform/hosts/ssh.md) - how to connect
- [tscli command-line reference](../api/cli.md)
- [Publishing changes](../platform/hosts/publishing.md) - how configuration normally reaches the server
- [Configure PHP](../technologies/php/configure.md) - including OPcache preloading
- [Roles and access](roles-and-access.md) - who can do what in the interface