What is the DJANGO_SUPERUSER_PASSWORD enviroment variable for?

[MrChadMWood]

I would like to make an AWS Fargate service to run the application. I need to map over the environment variables to accomplish this.

However, I can't find the source of this environment variable. It does not appear to be in the .env.example file.

  service:
    container_name: mathesar_service
    image: mathesar/mathesar-prod:latest
    environment:
      ...
      - **DJANGO_SUPERUSER_PASSWORD=${DJANGO_SUPERUSER_PASSWORD}**

I'm not sure if this should reference a pre-existing value, or if it will be used to declare the password. Can I have some background on this variable?

Secondly, will caddy-container still be required? I know it's used for serving some static files (among other things) -- does that mean it can't be removed easily?

Lastly, does the dev-team recommend any configurations for this sort of set up? Thanks!

Edit: I am referring to this docker-compose file as my source.

[mathemancer]

The DJANGO_SUPERUSER_PASSWORD variable would let you set a password via environment variable. It's not needed in your case: On the first run, the first time you go to the page, it'll ask you to set up an initial user. This is my recommendation.

For production, I do think you'd want to have the caddy-container . Especially if you're planning to expose the installation to the internet. It:

• Serves static files (as you noticed), and
• Automatically sets you up with the cert for SSL connections (i.e., https).

I'm quite curious about your setup on Fargate. Will you also use RDS for the DB? I've considered using a similar setup for some of our internal installations, but it seems like kind of overkill. What scale are you planning for? I.e., how many users?

Please let me know if you have more questions.

[MrChadMWood]

I want the Mathesar settings and whatnot to be persistent, and I assume that means it's application database should be in RDS as well. Would this be suffice for use as the application database?

CREATE DATABASE mathesar_django;
CREATE ROLE mathesar LOGIN PASSWORD 'mathesar';
GRANT ALL PRIVILEGES ON DATABASE mathesar_django TO mathesar;

Or is a superuser needed?

[mathemancer]

Does it make any sense to include the watchtower, or maybe it's better to just use the latest tag and rebuild the container when I want to update the software. What do you think?

This is perfectly fine. In fact, as I think about it, I don't think the watchtower container will work properly, since ECS isn't actually a docker environment. So, you'll need to do manual updates anyway.

I want the Mathesar settings and whatnot to be persistent, and I assume that means it's application database should be in RDS as well. Would this be suffice for use as the application database?

CREATE DATABASE mathesar_django;
CREATE ROLE mathesar LOGIN PASSWORD 'mathesar';
GRANT ALL PRIVILEGES ON DATABASE mathesar_django TO mathesar;

Or is a superuser needed?

No superuser is needed. The setup you describe is perfect.

[MrChadMWood]

Thanks again. I'm considering changing my approach a bit, and instead using a single reverse proxy to route traffic to several different tools (including mathesar) on various machines. I want this single reverse proxy to handle automatically setting up SSL certs for all my machines.

The fact that caddy is helping with serving files worries me though. Even with this setup, would you still recommend keeping caddy for Mathesar? I guess I would just use my network level reverse proxy to route to caddy whenever a request for Mathesar is made.

[mathemancer]

In theory, you could use that reverse proxy to serve static files. Are you planning to use one of AWS's options for that? Alternatively, you could configure the caddy container to serve static files for Mathesar, as well as route to other machines.

[MrChadMWood]

It was really a toss up between NGINX, Traefik, and Caddy. After doing a bit of research on all three, I think we're going to stick with Caddy. So, I'll just have it supply the needed files as well as route to other machines -- as you suggested. Thanks for the help!

[MrChadMWood]

Thanks @mathemancer. Do you have any recommendations for minimum cpu and memory?

[mathemancer]

• For the main web service container, I think you're good with 1 vCPU and 4GB RAM.
  • honestly, you could probably get away with 0.5 vCPU and 2GB, but I haven't tested going that low for any extended amount of time.
• For the caddy container, I think you'd be okay with 0.25 vCPU and 1GB RAM.
  • Again, you could go lower (i.e., I'd try the minimal config of 0.25 vCPU and 0.5GB RAM)
• As for the RDS instance, I think you'd want at least 4GB of RAM. 8GB would probably be better, with whatever the default vCPU setup is at those memory sizes.

If you end up experimenting with those lower-power configs, I'd be pretty interested in feedback on whether they work.

Please let me know if you have any other questions.