Use systemd to run QuestDB as a system or user service. This guide will demonstrate an initial configuration which you can use as the basis for your installation scripts. It will also demonstrate how to setup and start a QuestDB systemd service.
The prerequisites for deploying QuestDB with systemd are:
- A Unix machine supporting systemd
The following commands inform a basis for your systemd service. Prior to running systemd, you will require some directory structure and a binary for QuestDB. Depending on your specific needs and operational preferences, your commands may differ. The goal is to give you a helpful starting point for the example service. The example presumes that you have used a privileged user to create a user with appropriately scoped permissions.
Your QuestDB configuration is done in a
server.conf file. The
file is populated with safe defaults on first startup if it does not exist. It
is common for user's of QuestDB to stick with the default configuration.
However, should you choose to update your own and serve it via a scripted method
or similar, you may do so.
Read more about the available options in our Configuration reference page.
Create a new file called
The example below is a recommended starting point. Note the default QuestDB
service configuration and system paths in line with the above example. Next,
questdb.service file and add the following:
Next, move your
questdb.service file into your user's
Enable the service:
Start the service:
Check out the service status:
Your QuestDB instance should now be accessible at localhost, with services available at the following default ports:
- Web console & REST API is available on port
- PostgreSQL wire protocol available on
- InfluxDB line protocol
9009(TCP and UDP)
- Health monitoring & Prometheus
As an operator, you can decide whether to run systemd as the "system" from root
permissions, or a user with its own privileges. At the system level, root is
required to make changes to the
systemctl application. Services created this
way will start and stop when the system is restarted.
Unlike at the system level, user services will start & stop as the user session
is activated or de-activated. You also do not need to apply
sudo to make
changes to the services.
Consistent with the examples on this page, we recommend scoped users.