wg-easy VS docs

Check out wg-easy on GitHub. There is also a wg with pinole on their page. Works so easily together. https://github.com/wg-easy/wg-easy

sounds like you just want wg-easy.

This wg-easy?

Definitely not an OSI approved license, but does look like they made an attempt in the spirit of GPL, no?

https://github.com/wg-easy/wg-easy/blob/master/LICENSE.md

> You may:

Use this software for yourself;

Use this software for a company;

Modify this software, as long as you:

Publish the changes on GitHub as an open-source & linked fork;

Don't remove any links to the original project or donation pages;

You may not:

Use this software in a commercial product without a license from the original author;

wg-easy running in Docker. Then access it using WireGuard on my mobile devices.

Just plain wg-easy (wireguard with frontend). No 3rd parties involved, just me & my endpoint

I suggest running a VPN server like wireguard (very easy to install on phone and set up using https://github.com/wg-easy/wg-easy) and have the port open only to that. The VPN will do the rest in terms of NATing ports and whatnot.

https://github.com/wg-easy/wg-easy (7.6k stars)

I use wg-easy for now https://github.com/wg-easy/wg-easy

I will recommend you review the documentation for the official Postgresql docker images which you can read here.

This is the full documentation for these images. Please note, this page has links to Docker official documents on volumes, etc., which are necessary to run images such as this.

We've just followed the official documentation to add a PostgreSQL database server. This will act as an application container, as our app will soon be depended on it. And in order to make sure that the database container is always started whenever we start our application container, we've added a new depends_on key to the app service and let it know which other service(s) it, well, depends on. This will make sure that the database server is up and running before the app. You may also have noticed that we've mounted volume to our database server's datapath a bit differently. This is known as "named volume". We'll discuss it a bit more in another part, it's not relevant to what we're learning here.

Nextcloud isn't hard to setup, follow the official doc https://github.com/docker-library/docs/blob/master/nextcloud/README.md

Looking at the setup for this (link here: https://github.com/docker-library/docs/blob/master/nextcloud/README.md), I am starting to understand a lot of the recent posts that we've seen & how much of a mess it still is :(

Coming back to nextcloud, the official readme of the nextcloud image has a few notes on how to set up both nextcloud versions.

Use the native command envstubst to replace the Auth Tokens in your Config File before starting NGINX. Example: https://github.com/docker-library/docs/tree/master/nginx#using-environment-variables-in-nginx-configuration-new-in-119

It's not clear why you want to split the web server (nginx) and the app (nextcloud). However, if you do have a good reason, you're in luck, they have a compose file that does just that: https://github.com/docker-library/docs/blob/master/nextcloud/README.md#base-version---fpm (version 2, but it'll work)