Application Server

The FullJS application server provides a robust, modular, and secure foundation for running server-side services. It combines modern architectural principles with deep Linux integration to deliver enterprise-grade capabilitie

Microservice Architecture

The FullJS applications server follows a microservice-based server architecture with deep systemd integration. The application server is represented as a Systemd target ([application].target), with each individual microservice corresponding to a systemd unit instance ([application]@[microservice]).

Adding and Removing Microservices from the Application Server

To add a microservice to the application server group (so it is managed by the target):

sudo systemctl enable [application]@[microservice]

To remove a microservice from the application server group:

sudo systemctl disable [application]@[microservice]

Note: Enabling a microservice (a.k.a systemd unit instance) only registers it with the application server (a.k.a systemd target) for automatic start at boot. It does **not** start the microservice immediately in the current session.

Starting and Stopping a the application server

To start the application server use systemd’s start command. If you are running as a non-root user, you will have to use sudo since this will affect the state of the operating system:

sudo systemctl start [application].target

To stop a running application server, you can use:

sudo systemctl stop [application].target

Keep in mind that starting an application server only affects the current session and does not configure it to start automatically at boot.

Enabling and Disabling a the application server

The above commands are useful for starting or stopping an application server during the current session. To tell systemd to start the application server automatically at boot, you must enable it.

• To start the application server at boot:

sudo systemctl enable [application].target

• To disable the application service from starting automatically:

sudo systemctl disable [application].target

Keep in mind that enabling an application service does not start it in the current session.

Starting and Stopping a Microservice

Each microservice runs as a separate systemd unit instance ([application]@[microservice]). To start a microservice:

sudo systemctl start [application]@[microservice]

To stop a microservice:

sudo systemctl stop [application]@[microservice]

As with the application server, starting a microservice instance only affects the current session and does not configure it to start automatically at boot.

Filesystem Layout

The application conforms to the Linux Filesystem Hierarchy Standard (FHS). Executables, data, runtime state, and configuration are separated cleanly:

• /srv/fulljs/[instance]/ – contains the deployed application
• /run/fulljs/[instance]/** – runtime files (e.g., sockets, PID files)
• /var/lib/fulljs/[instance]/** – persistent state data (e.g., storage files)
• /etc/fulljs/** – configuration files (if any)

Managing the FullJS Application Server

Starting and Stopping

To start the FullJS server use systemd’s start command. If you are running as a non-root user, you will have to use sudo since this will affect the state of the operating system:

sudo systemctl start fulljs@[instance]

To stop a running FullJS server, you can use:

sudo systemctl stop fulljs@[instance]

Enabling and Disabling Services

The above commands are useful for starting or stopping FullJS during the current session. To tell systemd to start FullJS server automatically at boot, you must enable it.

• To start the server at boot:

sudo systemctl enable fulljs@[instance]

• To disable the service from starting automatically:

sudo systemctl disable fulljs@[instance]

Keep in mind that enabling a service does not start it in the current session. If you wish to start the service and enable it at boot, you will have to issue both the start and enable commands.

Checking Status

To check the status of the server on your system, you can use the status command:

systemctl status fulljs@[instance]

This will provide you with the server state.

Customizing and Re-branding

You can rebrand FullJS to fit your project name. For example, if your app is called myapp, you can define services like:

systemctl start myapp@microservice1
systemctl start myapp@microservice2

Example Unit File

[Unit]
Description=myapp service
After=network.target auditd.service haproxy.service

[Service]
Type=notify
User=myapp
Group=myapp
RuntimeDirectory=%p/%i
StateDirectory=%p/%i
ExecStart=/usr/bin/fulljs /srv/%p/%i.jss
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
WatchdogSec=30
Environment="DBUS_NAME=com.mydomain.%p.%i"

[Install]
WantedBy=multi-user.target

This way, your services become first-class, brand-aligned components of your Linux environment, while keeping all the benefits of FullJS’s microservice infrastructure.