The dashboard is a graphical user interface which provides a central location for you to keep an eye on server statistics, personal usage information and your services.
By default, the panel is not installed on swizzin installations, you must select it during install or install it afterwards via SSH with the command:
Setup will create a virtual python environment (
/opt/.venv/swizzin) and then clone the github repository (
If nginx is currently installed, the dashboard is available at the web root for your IP/DNS:
If nginx is not installed, you can find the panel at
There should not be much need to alter config options, but a few currently exist. These options should be defined directly in
/opt/swizzin/swizzin.cfg. Please note, all config variables are uppercase:
ADMIN_USER- Previously referred to as the "master" user. (Default: User with UID 1000)
FLASK_HTPASSWD_PATH- The location of the htpasswd file to protect the panel with. (Default:
FLASK_AUTH_REALM- Text displayed during auth pop up
FORMS_LOGIN- Whether or not to use the newer forms based login. (Default:
HOST- IP address to bind to (Default:
PORT- Bind port (Default:
URLBASE- "Sub-path" to server the panel (Default:
/). Make sure to adjust your nginx config.
RATELIMIT_ENABLED- Define whether or not rate limiting is active for non-logged-in users. (Default:
RATELIMIT_DEFAULT- Customize the default rate limiting period. (Default:
"5 per minute")
DEBUG- Turn off production mode and turn on the debugger. Prints response times and displays Python errors in the browser instead of causing internal server errors (Default:
SHAREDSERVER- Defines if this server is a swizzin enterprise server, you will probably never need to set this (Default:
The systemd service file resides at:
On the left side of the dashboard, you'll find quick links to the currently installed applications on your slot. No need to remember the endpoints and ports yourself!
The dashboard provides metrics for server load, CPU usage, and the current network metrics for upload and download speeds.
If you have the
netdata package installed, you'll see an additional tab in the navbar for Stats.
You can find your disk quota here.
You can see at a glance whether or not your services are currently running. You can also start and stop services directly from the panel, if you just need to quickly restart a service without SSH-ing into your slot.
Application profiles can be adjusted to your needs by editing the file
/opt/swizzin/core/custom/profiles.py. While this file is largely just variable definitions, it is Python, so be aware that indentation is extremely important. Please note, it is imperative that you do not touch the
import definition at the top of this file.
Most of the application options are self-explanatory, nevertheless, things can get confusing. Here's a list of options you can currently define and their meaning/usage.
name- The name of the application
pretty_name- A pretty version of the name, meant for printing in html templates
process- The name of the process to search for when running
runas- The user of the process to search for when running
scheme- Use to force HTTP if reverse proxy is disabled (default: current http scheme, usually https)
baseurl- The base URL and/or port of the application. If undefined, no sidebar link will be created.
urloverride- A complete override of the URL. If true, will supersede a baseurl/scheme definition. Example:
systemd- The name of the systemd service (default:
img- The name of your brand app icon. This directive can allow you to reuse already existing icons (i.e. for a 4k radarr instance). (default:
True, the panel will use
systemctl is-activerather than searching
There is a very large performance penalty when enabling a service with
check_theD. The following response times speak for themselves.
Given the results, it is important to remember to use
check_theD sparingly. As such, it is not enabled by default in any default swizzin profiles.
If for some reason your application requires extra information specific to the user's context, the application's meta profile can be called with the user context.
If you want to edit the variables of already profiled applications, you simply need to make a new class definition while calling the same class as the template.
Let's take an application that many users request to make changes to: Plex. Say my Plex instance isn't at port 32400 for some reason (perhaps I have a custom docker container running). If I wanted my dashboard link to instead use port 31400, I can easily make this change by adding two lines of code to
It's not necessary to add any other already-defined variables unless you wish to change them. This layout will only override the definitions which have been altered by us in the custom profile and use the defaults for everything else. But why stop there? We can also do things like change the "Pretty Name" of Plex displayed on the panel.
Now, instead of "Plex" the sidebar link and service status name will be displayed as "PLEX MEDIA SERVER". Why am I yelling? I have no idea.
Another commonly requested task is adding link and service status for applications not managed by swizzin. For instance, some users may have a second instance of Radarr running which they use to manage their 4k libraries. Let's add a new definition -- it won't be based on anything else, so we'll start fresh and define everything we need to make the service show up.
Since we enabled the checking of systemd services for this unit, we should enable it for the regular Radarr unit as well; otherwise, we won't be able to tell which Radarr is actually running when checking if it is active.
In order to tell the panel to check for the new application, simply create a lock file using SSH with the rest of your swizzin applications:
Finally, if you want to add an application icon to the sidebar, simply add a similarly named .png (or use the
img variable) to the
/opt/swizzin/static/img/apps folder. i.e.
Once you're happy with your edits, don't forget to restart the panel:
You can always also try the general troubleshooting tips written in our guide. They might or might not apply, but asking these questions can often make you understand what is under the hood better and help you find what needs to be fixed. It's always worth a shot!
You're probably running some browser plugins which are causing interference with the swizzin panel due to the way basic http auth is being handled. Please try to disable the plugin, use a different browser or use a private session without plugins to confirm your login still works, and try isolate the issue before reaching out for help.
You can retrieve the logs of panel by running
sudo journalctl -u panel. The logs contain the output of the python application.
As of October 31st, 2020, the swizzin panel now does rate limiting to reduce the ability of an unauthenticated attacker to brute force basic authentication passwords against the swizzin panel. This rate limiting should not be in effect for logged-in users. If you wish to disable this behavior, you can define
RATELIMIT_ENABLED = False in