Production Deployment Checklist
This page provides a list of topics you may want to consider when deploying Weaklayer in production.
The Weaklayer Sensor can be configured to use HTTP or HTTPS to send data to the gateway. HTTPS should be used in a production deployment.
The Weaklayer Sensor uses the Fetch API to contact the Weaklayer Gateway.
Therefore the sensor will trust any TLS certificate that the browser would normally trust.
You can test this by visiting the Weaklayer Gateway address in your browser (
This page presents information on the Weaklayer licenses and source code locations.
You should be able to view it over HTTPS if your gateway certificate is trusted by the browser.
To turn on HTTPS in the sensor, set
https in the sensor configuration.
Note that Weaklayer HTTPS communication should work well with proxy devices that perform decryption for packet inspection.
The Weaklayer Gateway can be configured to listen for HTTPS connections instead of HTTP connections.
This requires generating crypt material for the gateway to use.
Once you have done this, set the
sensor.api.https.* options in the gateway configuration.
The "Let's Encrypt" project has some great resources on generating crypt material if you are unsure where to get started.
You may also want to use a load balancer / reverse proxy to perform TLS offloading for the gateway. In this scenario, the connection between sensors and a load balancer would be encrypted. Then the connection between the load balancer and the gateway is unencrypted. It is possible for this to be encrypted though. Leaving the second connection unencrypted is a common pattern in web application deployment since the load balancer and web server are normally very close to each other on a trusted network where there is little opportunity for man-in-the-middle attacks. There will be more information on using a load balancer / reverse proxy in the Gateway High Availability section.
Gateway High Availability and Horizontal Scaling
For production deployments, you may want to run more than one instance of the Weaklayer Gateway to achieve high availability and horizontal scaling. This is done by placing multiple instances of the Weaklayer Gateway behind a load balancer / reverse proxy. Both TCP and HTTP load balancers will work, but you may want an HTTP load balancer to perform TLS offloading.
The Weaklayer Gateway is a stateless application that does not maintain session data. Additionally, there is no communication that happens between gateway instances. However gateways behind a load balancer should have the same configuration. This will ensure that gateway instances are identical so when one instance becomes unavailable, another can pick up where it left off.
You should also consider enabling session stickiness on your load balancer. This will result in data from a given sensor going to the same Weaklayer Gateway instance. Session stickiness is not required by any means, but it might give more useful behavior depending on your configuration. For example, if you are using the filesystem output, session stickiness will result in all data from a given sensor being in a single gateway's files, which may ease downstream processing.
There are several considerations for secrets that are provided through the gateway configuration.
The first consideration is that you should not use the example values in a production deployment. Token secrets and install key / verifier pairs should be securely generated with the gateway CLI.
Next you may want to consider secret rotation strategies for secrets. There are mechanisms in the gateway for gracefully rotating token secrets and install keys / verifiers. You may specify past token secrets so tokens signed with these pasty secrets will be accepts, but no new tokens will be issued with them. Additionally, you can provide multiple install verifiers for the same group. Sensors that provide an install key that matches a single verifier will have a successful installation.