Administrator access

How administrator rights work on a TurboStack host - why your system user is not root, and the small set of commands it may still run.

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, 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. 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. 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 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 handles them.

SSH access - how to connect
tscli command-line reference
Publishing changes - how configuration normally reaches the server
Configure PHP - including OPcache preloading
Roles and access - who can do what in the interface