Productionize LiveReview
You can follow the article for Demo Mode and make sure the software is running first in your target server.
When you run lrops.sh status you should something like as follows:
The next task is to turn on the production mode.
Run lrops.sh set-mode prod and enter "y" to continue:
You should see success message:
Run lrops.sh show-mode to confirm:
The goal now is to:
- Point
yourdomain.comorlivereview.yourdomain.comto your production server - Get a reverse proxy to handle requests
- Pass the requests correctly to our docker containers
- Make sure SSL (https) works correctly
This can be achieved in many ways. For reverse proxy you can use nginx, caddy, apache or any other tool of your choice.
The first task is to setup an A record in your DNS manager such as Namecheap, GoDaddy or AWS Route 53, etc
so that yourdomain.com or livereview.yourdomain.com routes traffic to your server's public IP A.B.C.D.
For example, in hexmos.com case - you can see the namecheap configuration as follows:
You can use DNS Propagation Checker or dig command to validate this.
It looks like this in our case - you can still a few locations still waiting to get propagated:
Run lrops.sh help nginx or lrops.sh help caddy or lrops.sh help apache to get reverse proxy-specific
instructions on how to route this traffic to the containers.
High level instructions for nginx are as follows:
1. Install Nginx:
sudo apt update && sudo apt install nginx
2. Copy the LiveReview Nginx template:
sudo cp ~/livereview/config/nginx.conf.example /etc/nginx/sites-available/livereview.conf
3. Edit the domain name:
sudo sed -i 's/your-domain.com/your-actual-domain.org/g' /etc/nginx/sites-available/livereview.conf
e.g. for livereview.google.com:
sudo sed -i 's/your-domain.com/livereview.google.com/g' /etc/nginx/sites-available/livereview.conf
4. Enable the site:
sudo ln -s /etc/nginx/sites-available/livereview.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
Use the .conf suffix for the filename. Some nginx builds include site files with
include sites-enabled/*.conf, and a file without the extension is then silently ignored -
nginx -t still passes and nothing appears to be wrong.
After each step you can run:
lrops.sh doctor yourdomain.com
It tests each layer separately - the app, this machine's nginx on port 80 and on port 443, and what the public internet actually receives - and then tells you which layer is the problem. Most "the site is down" situations are just those layers disagreeing:
app :8888/health 200
app :8081/ 200
origin :80 200
origin :443 -
public https:// 521
At this point - you can actually visit the URL to get the http (insecure) version of the app:
Finally - you will need SSL certificates to secure the configuration. You can do lrops.sh help ssl to get
some guidance. Usually you can use let's encrypt to get a certificate for free
using their certbot command. You can also probably get it via Cloudflare or your organization's administrators
can help you get a certificate.
Here are general guidance on getting SSL certificate and configuring:
OPTION 1: Automatic SSL with Caddy (Recommended for new setups)
- Handles certificates automatically
- Zero manual certificate management
- See: lrops.sh help caddy
OPTION 2: Manual SSL with existing reverse proxy
- Use your existing nginx/apache setup
- Obtain certificates with certbot or your preferred method
- Configure your reverse proxy to use certificates
OPTION 3: Cloud/managed SSL
- Use CloudFlare, AWS ALB, or similar services
- Terminate SSL at the load balancer/CDN level
- Point to your LiveReview ports (8888/8081)
REQUIREMENTS FOR ALL APPROACHES:
- Domain pointing to your server (DNS setup)
- Ports 80 and 443 accessible
- LiveReview running on ports 8888 (API) and 8081 (UI)
REVERSE PROXY ROUTING:
Route /api/* → http://127.0.0.1:8888
Route /* → http://127.0.0.1:8081
GENERAL SSL GUIDANCE:
- Let's Encrypt is free and widely supported
- Use certbot for most manual SSL setups
- Configure automatic certificate renewal
- Test your SSL setup: https://www.ssllabs.com/ssltest/
In my particular case, I had to the following:
Get the certificate only:
sudo certbot certonly -d livereview.hexmos.com
Once the certificate was ready, I opened up the configuration file:
vim /etc/nginx/sites-enabled/livereview.conf
# deleted the http-only block, uncommented the https block (there's already a template)
nginx -t # returned OK, no syntax errors
sudo systemctl restart nginx
This is a pretty standard thing to do for setting up any website or webapp. If you are facing any issues in your particular circumstance in getting this to work - just Create an Issue and our team will help you out.
The result of this step is that you can open https://yourdomain.com or https://livereview.yourdomain.com to
get the login screen for LiveReview. And when you look at the URL bar - you can see that there is a valid SSL
certificate protecting transactions with the service.
I did a hard reload for https://livereview.hexmos.com in my browser, and I got the app as expected:
This is worth reading before you conclude something is broken. If your domain is proxied through Cloudflare, finishing the four nginx steps above can still leave you looking at an error page, because those steps produce an HTTP-only origin while Cloudflare, depending on its SSL/TLS mode, connects to your server over HTTPS on port 443.
Cloudflare's own error code tells you exactly what is wrong:
| What you see | What it means | Fix |
|---|---|---|
| 521 | Cloudflare is connecting over HTTPS, but your server has nothing listening on port 443 | Complete the SSL step below, or set Cloudflare's SSL mode to Flexible |
| 526 | Your origin certificate is not trusted - Cloudflare is on Full (strict) and your certificate is self-signed | Use a real certificate (Let's Encrypt) |
| 525 | The TLS handshake with your origin failed | Check ssl_certificate / ssl_certificate_key paths |
| 522 | Cloudflare could not reach your server in time | Usually a firewall blocking Cloudflare's IPs - check sudo ufw status
|
The most reliable setup, and the one we recommend, is to always terminate TLS on your own server with a real certificate. That single configuration is correct whether or not a CDN is in front of you, and whichever SSL mode it uses:
| Your setup | Origin with port 80 + port 443 and a real certificate |
|---|---|
| No CDN, DNS points straight at the server | Works |
| Cloudflare, Flexible mode | Works (Cloudflare uses port 80) |
| Cloudflare, Full mode | Works (Cloudflare uses port 443) |
| Cloudflare, Full (strict) mode | Works (the certificate is trusted) |
An HTTP-only origin fails two of those four, and a self-signed certificate fails one - which is why it is worth doing properly the first time rather than discovering it later.
One thing to keep in mind while issuing a certificate: Let's Encrypt's HTTP-01 challenge has to
reach /.well-known/acme-challenge/ on your server. The bundled nginx template keeps that path
served over plain HTTP for exactly this reason, so leave it in place. If your CDN blocks it, use
a DNS-01 challenge instead.
The containers publish ports 8081 and 8888 on all interfaces, so http://YOUR_SERVER_IP:8081
reaches the app directly - bypassing your reverse proxy, your TLS, and your CDN. Before going
live, either firewall those ports or bind them to localhost in ~/livereview/docker-compose.yml:
ports:
- "127.0.0.1:8081:8081"
- "127.0.0.1:8888:8888"
Then cd ~/livereview && docker compose up -d --force-recreate. lrops.sh doctor warns you if
it detects this.
In production, if you try to add a Git connector, it'll ask you to configure a domain URL first:
The reason for this is - because we want to configure how platforms such as Gitlab/Github/Bitbucket can send webhooks/notifications to our server.
You can Goto Settings -> Instance. There usually the path will be pre-filled via the address bar. If not you can type it out and hit "Save":
Now if you come back to Git connectors, you will have the buttons visible and the warnings will be gone:
You can follow Add Git Providers page if you haven't already to add at least 1 git connector to your LiveReview.
You should have at least 1 connector like this in the "Your Connectors" section; click the "Cog" icon to see settings for that connector
You'll see the "Repository Access" section:
Here, we have three categories possible:
- Not connected: It means - the only way to trigger a review is by using LiveReview's web UI with "New Review"
- Manual Trigger: You can assign a reviewer in the Gitlab/Github/BitBucket MR pages and LiveReview will pick it up and post review comments.
- Automatic: LiveReview will automatically trigger a review when it is opened or a change is posted to it. As of now, this feature is not implemented yet.
To enable manual trigger, if it is not already enabled, just click on "Enable Manual Trigger for All Projects"
In the panel below - you can see project level progress:
You can trigger a review now by assigning a reviewer in the code host's MR interface:
