Is this Docker Compose structure possible with Caddy?

[tetratheta]

I know this looks like a trivial question, but I’m not sure if this structure is possible with Docker Composer and Caddy or not.
Sorry if this question looks like a trivial / lazy question a lot.

Since this question is not actually asking about ‘How to configure Caddy?’, I removed the default template for asking question because that template looks like for asking ‘How to configure Caddy?’ to me.

If this structure is possible with Caddy, I will look Caddy documentation more precisely and come back if I face a problem while configuring Caddy.

---

I want to serve multiple ‘things’(website/database etc.) within single Oracle Cloud instance. It is free tier instance but I think that is enough for this plan.

The reason I used example.com as domain is I haven’t actually configured my DNS records with all of these subdomains like db.example.com or website.example.com yet. When I actually configure Caddy, I will first configure my DNS for all of these subdomains will point to same IP address with A type. (My DNS provider doesn’t support DDNS)

---

Here is brief concept of my plan in form of image.

There were two images, but I can only post one image for now.

In below, there are same contents in text form, with more detailed description.

---

I want to serve these five ‘things’ with Docker Compose and use Caddy as ‘gatekeeper’.

Web Server (HTTPS) - Caddy

Caddy will redirect every traffic to each of sibling containers depending on what subdomain that client accessed with.

For example, if client accessed with db.example.com, the traffic will be redirected to ‘Database’ container. Client won’t be able to access other containers with that subdomain.

With Caddy, I can automatically enable HTTPS for all of my websites and I really like that.

Since Caddy is the only thing that interacts with Internet, client can’t directly access other containers!
All sibling containers will communicate with HTTP, not HTTPS. (TLS Termination Proxy)

Database

The database will be PostgreSQL. I will change default port from 5432 to 5757 because of security.

I’m not sure, but if I remember correctly, all sibling containers still be able to access Database with default 5432 port, even though I change it with Docker Compose.

Since I need to access Database from another machine, I must open port of Database to public.

Gitea (+ Web Interface)

I want to host static webpages made with Hugo and Gitea will host its ‘source code’.

The reason why I want to use Gitea is, I think the repository’s size will exceed 5GB which is limit of GitHub repository.
Since webpage will contain a lot of images, even though I convert them to WEBP image for file size reducing, the repository’s size will exceed 5GB. Gitea is self-hosted so I guess it doesn’t have such limit.

I need a ‘safer place’ that I can save ‘source code’ of my website, safer than my local hard drive.

Shlink

I also want to provide myself a Link Shortening Service. I know there are a lot of service of this kind like b**.ly, but I want my shortened link managed by myself. Many of those kind of service limits ability of managing shortened link without paying to them.

‘Gitea Pages’

I know Gitea doesn’t provide ‘Gitea Pages’ yet. I think I must make a script that generates static website when I push to Gitea repository.

My plan is, when Gitea Push event happens, it will generate static webpage with Hugo and serve it to public.

Or I can just generate static webpages locally and push it to another branch, and make this container ‘pulls’ website from Gitea repository and serve it.

Another Website

I also want to host another website. Maybe this would be written with Node.js or PHP. Its source code will be hosted on GitHub private repository, but website will be hosted in this container.

---

This is my plan and I really want to know if this plan is possible or not. I’ve tried to use NGINX first, but I got lost in a maze of NGINX configuration.

I’m not sure if I should provide ‘previous’ Docker Compose YAML configuration file’s content because this is partially tested with Docker Desktop (Windows) and I have to use it on Oracle Cloud (Linux). I used NGINX for this test too.

If you want to see that ‘old’ Docker Compose YAML configuration file, tell me. I will append its content below.

Thank you for reading this long story.

[emilylange]

Hi,

@tetratheta

Caddy will redirect every traffic to each of sibling containers depending on what subdomain that client accessed with.

For example, if client accessed with db.example.com, the traffic will be redirected to ‘Database’ container. Client won’t be able to access other containers with that subdomain.

With Caddy, I can automatically enable HTTPS for all of my websites and I really like that.

ye, you could set up Caddy this way. With the exception with the database, but I am getting ahead of myself:

@tetratheta

Database

The database will be PostgreSQL.

Caddy (much alike nginx and other proxies) isn’t able to “auto-https” your PostgreSQL (PSQL) database, because PSQL isn’t using http but instead its own protocol.
And that custom protocol also does its own SSL/TLS handshaking at the application layer.
See [Question]: TLS termination for PostgreSQL · Issue #48 · mholt/caddy-l4 · GitHub for a bit more details on that.

@tetratheta

I will change default port from 5432 to 5757 because of security.

Big no no.
You don’t gain any security just because you change some services’ port.
That would be Security through obscurity - Wikipedia

@tetratheta

Since I need to access Database from another machine, I must open port of Database to public.

Consider having a secure link between that other machine and your database.
That could be a VPN like wireguard or OpenVPN. Or perhaps a simple ssh tunnel should get the job done too.

@tetratheta

I’m not sure, but if I remember correctly, all sibling containers still be able to access Database with default 5432 port, even though I change it with Docker Compose.

Yes, that is true.

@tetratheta

The reason why I want to use Gitea is, I think the repository’s size will exceed 5GB which is limit of GitHub repository.
Since webpage will contain a lot of images, even though I convert them to WEBP image for file size reducing, the repository’s size will exceed 5GB. Gitea is self-hosted so I guess it doesn’t have such limit.

Consider using Git LFS for your images and media files, then.
That’s exactly what Git LFS was made for

@tetratheta

‘Gitea Pages’

I know Gitea doesn’t provide ‘Gitea Pages’ yet. I think I must make a script that generates static website when I push to Gitea repository.

My plan is, when Gitea Push event happens, it will generate static webpage with Hugo and serve it to public.

Or I can just generate static webpages locally and push it to another branch, and make this container ‘pulls’ website from Gitea repository and serve it.

There are many ways to do that, ye.
Any specific questions?

---

Okay, so considering your original question was

@tetratheta

If this structure is possible with Caddy, I will look Caddy documentation more precisely and come back if I face a problem while configuring Caddy.

then yes, everything you just mentioned is absolutely possible with Caddy.
Though I would highly recommend looking into another way to expose (or rather share) your database
If you insist having your database proxied via Caddy, then have a look at GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy and perhaps caddy-ext/layer4 at master · RussellLuo/caddy-ext · GitHub.
Keep in mind that you will have to configure PostgreSQL to do the SSL/TLS termination, at which point you could also just use ports: in your docker-compose.yml instead.

Please feel free to ask any further question
There is just so much to unpack here, and it is not immediately clear to me where you need help or more details whatsoever

[tetratheta]

First of all, thank you for your kind answers!

@emilylange

then yes, everything you just mentioned is absolutely possible with Caddy.
Though I would highly recommend looking into another way to expose (or rather share) your database
If you insist having your database proxied via Caddy, then have a look at GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy and perhaps caddy-ext/layer4 at master · RussellLuo/caddy-ext · GitHub.
Keep in mind that you will have to configure PostgreSQL to do the SSL/TLS termination, at which point you could also just use ports: in your docker-compose.yml instead.

Thank you again for this confirmation. I think re-designing the structure of my Docker Compose would be a good start.

Like:

• Use Git LFS only for images (No Gitea - Host codes in GitHub, Images in OC)

---

These are just trivial words.

@emilylange

Caddy (much alike nginx and other proxies) isn’t able to “auto-https” your PostgreSQL (PSQL) database, because PSQL isn’t using http but instead its own protocol.
And that custom protocol also does its own SSL/TLS handshaking at the application layer.

The client outside of Oracle Cloud is written with Java so I should use JDBC for accessing database.
I’m not sure, but according to this document of PostgreSQL JDBC Driver, I can include certificate files in client app for securing connection.

@emilylange

Or perhaps a simple ssh tunnel should get the job done too.

I haven’t coded SSH tunnel in Java before, but this looks nice too.

@emilylange

Consider using Git LFS for your images and media files, then.
That’s exactly what Git LFS was made for

Since GitHub’s Git LFS size limit is 2GB for free tier, I think running Git LFS server on Oracle Cloud would be a good idea.
If I self-host Git LFS server, there is no limit about total size of LFS. Also, I don’t need to worry about HTTPS because LFS doesn’t support HTTPS, only supports HTTP.

---

Thank you for helping me clearing my plan.
For instance, I can exclude Gitea on my plan and replace it with Git LFS server. Both websites can be built locally and ‘pushed’ to Oracle Cloud. These would lighten the load of configurations.