FullJS application server is a JavaScript runtime built on Chrome’s V8 JavaScript engine. The application server is multi-threaded and uses event-driven, non-blocking I/O model that makes it lightweight and efficient for running separate isolates of javascript applications.
Application Server Architecture
Microservice Deployment
FullJS is structured as a microservice-based application server.
Systemd Integration
FullJS instances are defined and managed using systemd. Each individual instance is launched and managed as a separate systemd service using the naming pattern:
systemctl status fulljs@[instance]
HAProxy Integration
FullJS integrates directly with HAProxy, acting as a control interface to route traffic dynamically at runtime. Each microservice runs behind HAProxy, which forwards incoming requests to the appropriate backend based on configured endpoints.
- Reverse proxy routing enables clean separation of responsibilities
- All service endpoints are exposed through HAProxy
- Backend configuration is updated live
FullJS uses the [HAProxy Runtime API](https://www.haproxy.com/documentation/haproxy-runtime-api/) to manage HAProxy configurations on the fly. This enables dynamic registration of services, health checks, and traffic routing without requiring HAProxy reloads.
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)
Starting and Stopping FullJS application server
To start the FullJS server use the 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 the stop command
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, use the enable command:
sudo systemctl enable fulljs@[instance]
To disable the service from starting automatically, you can type:
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 FullJS server 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.