Recommendations for self hosting a flutter web portal

Been researching a few sites and documentation, looking for some best practise advice on first production deployment of a portal I'm building for a client. This is something completely separately hosted from their main website.

Firstly, its obvious now, but coming from other frameworks, I didn't realise the flutter web front end should ideally be hosted on a separate server/container than the appwrite docker containers. This might be something to add to a beginners section for those new to Appwrite or those coming from other frameworks. My questions though for a secure production deployment:

1. DNS for servers
   Portal will be hosted with portal.<client_name>.com. Should Appwrite be hosted as (1) appwrite.<client_name>.com, or (2) appwrite.portal.<client_name>.com?

2. Flutter web hosting
   Any suggestings for hosting on the same docker server a separate container to host the flutter-web code (portal.<client_name>.com). E.g. just use a generic nginx:latest?

3. Firewall for appwrite containers/traefik
   Given the above separate containers, is it ok to completely firewall off the appwrite public IP address to only be accessible by my and its own IP address for console/api access? i.e. The flutter-web frontend shouldn't be askng the browser to make direct calls to the appwrite URLs, the flutter-web code will do this effectively from/to the same IP address its hosted on? (I realise if later I add mobile, this would change.)

4. Ports for hosting appwrite
   Given the above scenario, the single IP address the docker container server has, the flutter-web container (nginx?) would bind/export port 80/443 and the appwrite container would bind/export alternative ports, e.g. 8080/8443, which is firewalled off from the open internet. Is this correct?

Thanks for any advice or pointers. I haven't found a system overview or deployment diagram/discussion that helps me to know the best practise ways to do this deployment for a flutter web front end. Please let me know though if there is!

1. This is pretty opinionated, you can host wherever you like to host the appwrite backend and the client front end. Usually its good to host both on a single domain, separated by subdomains as you've suggested.

This is what I do personally -
Backend @ cloud.website.com
Frontend @ website.com
Other Misc. Frontends and Functions @ blog.website.com Or funcX.website.com

Nginx takes care of everything port bindings for me.

2. You can use different subdomain which afaik will have different stacks, unless you use docker for both. Flutter Web might have just the JS & Html files, not sure this explicitly requires a docker container.

3. Seems right again, adding the mobile will require a publicly accessible appwrite backend. But this is manageable until you create the mobile app.

4. Looks correct to me. As long as the ports are free, you can bind them to whatever project you'd like.

2. For the hosting you can use any kind of tool to host it, since It's static content. You can even use Cloudflare pages that is completely free

ok thanks for the feedback, appreciate it

I'll need to double check what the flutter web-ui actually needs the browser to be able to access as to whether I can firewall off the appwrite ports from the internet.

Is there any specific guides for my use case or similar that might apply for production self hosting? I couldn't seem to find anything close enough to what I was trying to do and if there are better ways of doing things using Appwrite as the back end, nows the time for me to implement them

I guess I better check that's all my flutter web ui is actually producing and if so, any type of webserver should do. But that would imply then that the browser will make JS calls to the backend, so the browser/open internet is going to need access to my appwrite ports.

I don't there's a guide as this is just standard. You simply decouple your logic here like -

1. Host a flutter-web app on port 4444, use Nginx to forward requests from this domain to port 4444.
2. Install appwrite as usual on your ports, use Nginx to forward requests from this domain to your selected port.

PS: there could be other ways than just nginx, but I've used it so I gave it as an example.

For firewall thingy, you are correct [imo] in your initial message.

Hmm ok, I'm wondering if Appwrite is already using traefik as an internal proxy, whether its ok to just extend it to use it for another nginx container in the same docker-compose.yml. I guess that makes upgrading Appwrite more difficult in the future if its modified too much. So I'm just wondering if Nginx in its own separate container, but accessing the same Docker network is the way to go. I think I saw an example of using Nginx Proxy Manager to do this.

I am not too fluent on Docker to comment on Docker Container x Nginx as a combination. Feel free to ask on around or on StackOverflow or wait until one of the Core member bumps in here ✌️.

Thanks for your suggestions though, its been very helpdul. I've got some ideas to try.
You wouldn't happen to have an Nginx config you could share though of something similar/related? I'm reasonably comfortable with Nginx, (more than Traefik) so would probably go that way and try to isolate Appwrite and the front end.

I use CloudPanel, so every domain/subdomain I add gets their own Nginx setup which is easily modifiable. Infact, 90% of the time, there's really no modification required as the new domain/subdomain is automatically mapped to a given port on initial configuration.

Ah ok I see. I like to generally do it via the CLI with the config files, but I think I've found some examples that might apply.

The flutter app interacts with the Appwrite backend directly so the app should have direct access to the appwrite backend

Yes, I think my suggestion to firewall off the Appwrite ports is wrong, because as you say, it will need the browser running the flutter web ui to be able to directly call it.

So I was trying to stop attempts from the open internet to access the Appwrite console. So this looks like it would be better managed by a reverse proxy (e.g. nginx proxy manager) to block/disable access to /console url to all but my specific IPs. In which case, I could even export all containers to just localhost ports and then use the reverse proxy to map specific url paths to each localhost port and default url will be the flutter web ui web server with just the appwrite url paths mapped as required for api access.

This should allow me to run everything from the same single IP server with separate Docker containers.

As my initial use case is just a few portal users, a single server would more than manage this load. If the number of users/load increases, I can split it onto separate servers later.

I'd really like to see an example of a production config of a reverse proxy manager for doing all this, would just give me more confidence I'm not opening up parts of appwrite that should not be exposed to the open internet.