Metabase on same server as Frappe with SSL

Frappe Framework
1

Hello all

I’m very impressed with the ease of use of Metabase. I’ve installed it locally and it works perfectly. http://localhost:3000

I now want to use it in production and have installed it on the same AWS EC2 instance I have my Frappe (v14.26) running on. I’ve installed Frappe via bench (v5.16) and also configured SSL via bench which makes use of certbot.
Frappe works fine using the https protocol and a DNS entry to point to the EC2 IP address. All happy days… https://edc.companyname.co

Now I want to add Metabase to the same SSL configuration, but I have no idea as to where to even start.
I do not even know which are the correct questions to ask on this forum :thinking:

Do I need to configure a reverse proxy on nginx?
Can I use the same SSL certificate as is used by Frappe?
Do I need to configure a separate DNS entry for Metabase?
Do I need to open port 3000 on the server?

Please help :pray:
I have very limited experience when it comes to networking. Every little bit of advise will help.

2

Nginx will handle it well My understanding is that 1st you have to add A record for Metabase in your DNS and then manually install SSL from Lets Encrypt.

If you have used bench command so most probably Metabase site has also been added to nginx v

1 Like
3

So, I don’t like Metabase for the simple fact it’s a software using Java, but heck, we have it running already.

What we did is:

  1. Installed Metabase on the same server as your Frappe instance (you don’t wanna open up 3306 for public),
  2. Created A record in our DNS,
  3. Created an Nginx config for Metabase,
  4. That was basically it from structure side of things.
  5. Installed certbot classic, called Certbot for SSL, and all done.
1 Like
4

A lot of info here already, but just to answer your specific questions:

The situation you’re describing is exactly what a reverse proxy is designed to simplify. If you’re using ERPNext with a standard production setup, you’ve already got a reverse proxy.

NGINX sits on the public edge of your server, listening to standard web traffic ports like 80 and 443. Then, based on a set of rules you define, NGINX will proxy (route) traffic to the internal interface of whatever services you want to offer. In this case, it might route some traffic to metabase (localhost:3000) and some traffic to Frappe (typically localhost:8000).

There are several ways for web requests to communicate which service they want, but the most common are to use different ports or different domains. For production setups, domains tend to be preferred. You might, for example, tell NGINX to route all traffic to edc.companyname.co to ERPNext and all traffic to mb.companyname.co to Metabase.

I tend to prefer separate certificates, but it doesn’t really matter. You can instruct certbot to expand the certificate you already have or you can create a new one just for metabase. The effect is the same as far as the end user is concerned. If you’re letting Frappe handle the certificate generation, it’s probably easier to create a separate one for Metabase. If you’re generating the certificate yourself, it doesn’t really make a difference.

If you want to serve metabase from a different domain name, yes.

If you want to skip the reverse proxy and just expose Metabase to the world directly, you should be able to do that too. I don’t know enough about Metabase to know if this is a recommended approach.

Personally, I just find it cleaner to use a reverse proxy. DNS does a great job of what it’s designed for, which is to give abstraction and flexibility to server deployments. If you just serve Metabase directly from https://edc.companyname.co:3000, it will potentially be more complicated down the road if you later decide that you want to run the two applications on separate machines.

3 Likes
5

Thanks so much @peterg

Your answers are always so detailed and considered.

We are so fortunate to have you on this forum. :100:
Thanks for all you contributions over the years!

3 Likes