FastComments On-Prem allows you to deploy our live commenting solution, including all moderation and admin tools, on your own hardware.

This means you have control over your data, and the commenting system can be restricted to your local LAN or corporate network.

Required Components

For On-Prem, FastComments consists of an application server and a database. We have simplified the deployment so that the application can serve all traffic directly without adding other components.

The application server is provided in a Docker image and can be deployed with any container management solution.

The database, MongoDB, can be self-hosted or hosted by another provider like AWS DocumentDB or MongoDB Atlas.

FastComments is currently tested with MongoDB 7, however we aim to be DocumentDB compatible to ease deployment.

Instance Sizes

You will find that FastComments is fairly well optimized and doesn't require large machines for the application itself to keep low P99s.

All batch and cron jobs use streaming to limit total memory usage.

The tables below for the application server and database can assist with sizing.

Application Server Instances

For example, a single core serving around 100 comment threads per second usually never uses more than 250mb RSS.

Database Server Instances

Sizing the database depends on working set size, which is the amount of data you access at a given point in time, as well as concurrent requests.

FastComments is fairly kind to MongoDB, in that for the hot queries it uses index hints, streaming cursors, and has concurrency limits in various areas to prevent overloading of downstream systems.

The following is a general guideline on database instance sizes. Note that this is per instance, not total resources in the cluster.

The above tables are conservative estimates. You may find actual requirements differ based on your specific configuration (page sizes, comment volume, etc).

FastComments utilizes environment variables for configuration. The following list outlines all supported variables that are relevant to On-Prem.

Note that all domain-related variables use the _HOST or _ADDR postfix. The difference is:

• _HOST: example.com
• _ADDR: https://example.com

The EMAIL_CONFIG_PATH should contain a path to a JSON file with the following example format:

Email Config

Copy

1

2{

3 "defaultDKIM": {

4 "domainName": "mycompany.org",

5 "keySelector": "2024",

6 "privateKey": "-----BEGIN PRIVATE KEY-----\nABCDEFG\n-----END PRIVATE KEY-----"

7 },

8 "providerTransports": {

9 "yahoo.com": "specialTransport"

10 },

11 "defaultTransport": "mailgun",

12 "transports": {

13 "mailgun": {

14 "host": "smtp.mailgun.org",

15 "port": 587,

16 "secure": false,

17 "auth": {

18 "user": "admin@somewhere.com",

19 "pass": "password"

20 },

21 "tls": {

22 "ciphers": "SSLv3"

23 }

24 },

25 "specialTransport": {

26 "host": "smtp.someplace.org",

27 "port": 587,

28 "secure": false,

29 "auth": {

30 "user": "admin@example.com",

31 "pass": "password"

32 },

33 "tls": {

34 "ciphers": "SSLv3"

35 }

36 }

37 }

38}

39

In the above example we define a default SMTP email transport called mailgun. We also define special transport that we use specifically for @yahoo.com emails. In some scenarios it is desirable to use a specific provider or sending IP for a domain to tune delivery. This is optional.

DocumentDB

When connecting to DocumentDB you will want to specify MONGO_ENABLE_SSL=true MONGO_SSL_CA=/some/path.pem to be compatible with default settings.

FastComments supports an automatic maintenance mode. If the database goes down, it can continue to serve popular comment threads.

Additionally, in maintenance mode, all comments are saved to BACKUP_DIR. They will be processed (checked for spam, etc) and saved once the system is back online.

It does this by determining, every hour, the top 100 most popular comment threads and caching their content on-disk. Determining the top 100 threads is already done from precomputed state, so it is not a heavy periodic job.

This is completely optional, and is only enabled if CACHE_DIR and BACKUP_DIR are set. This, of course, makes the application nodes stateful; however, it is state that can be lost at any time without causing the application to misbehave.

Note that in maintenance mode proper authentication of comment threads cannot be performed, so only threads that are safely considered public are periodically backed up.

In maintenance mode many features are not available.

The front-end code snippets and libraries for On-Prem are the same as the SaaS product. However, you must specify apiHost and the correct script path:

Comments Code for On-Prem

Copy

1

2<script async src="https://my.host.com/js/embed-v2-async.min.js"></script>

3<div id="fastcomments-widget"></div>

4<script>

5 window.fcConfigs = [{

6 target: '#fastcomments-widget',

7 tenantId: "demo",

8 apiHost: "https://my.host.com"

9 // ... you can also pass an SSO payload, etc.

10 }];

11</script>

12

The above is a very simple example. We could also use the first-party React, Angular, Vue, Svelte, etc., libraries.

The API can be accessed just like the regular SaaS product in that you would log in to the on-prem dashboard to create API keys and use those keys to access the API. The API endpoints are the same on-prem as they are for the SaaS product.

Your On-Prem FastComments installation can serve comments to multiple internal domains, for example app.mycorp.org and hr.mycorp.org. You can configure these separately but host them on one On-Prem setup by creating separate Customization Rules to configure their individual behaviors.

By default, FastComments assumes comment threads are public. To add a layer of security, it's recommended to create a Customization Rule with the Requires SSO option checked. This will cause all comment related endpoints to require SSO authentication.