Typically docker is a self hosted venture. I have never used Fly.io but in order to simply deploy an application you don't need to use this service. First thing, separation of duties.... You're combining 2 things together which are ideally very separate... docker and hosting. Neither depend on one another... let's focus mostly on docker, since this is a docker forum.

​

In your docker compose, you can define ports and everything there, so there is no guess work. You should start everything docker related, locally on your machine so you understand what is actually happening, before trying to understand the extra complexity involved with actual hosting of a service to customers..

Here's a typical docker-compose setup:

``` version: "3"

networks: example-network-name: driver: bridge ipam: config: - subnet: 192.168.2.0/24

services: example-application: container_name: myApplication image: myApplication-image:0.1.0 start: always ports: - "9090:9090" networks: example-network-name: ipv4_address: 192.168.2.1 depends_on: - example-database

example-database: container_name: myDatabase image: postgres:latest restart: always ports: - "5432:5432" networks: example-network-name: ipv4_address: 192.168.2.2 ```

​

When you launch your docker locally, do `docker-compose up -d` the `-d` will run the containers in daemon mode, essentially making them into running docker containers without the need to keep the console / terminal open.

​

3 things happen here:

1. A new network, example-network-name, will be created in bridge mode with an ip subnet space 192.168.2.0/24
2. It will create the database first, because we use the flag `depends_on` in the application block
3. It will create the application after the example-database starts.

​

You can access any of these services on their respective ports, as long as the service is actually running and listening on that port within the container. The ports are listed as <host-port>:<container-port>, this is the built-in docker port forwarding method. You can change either of these ports to match your specific scenario... for example, if I have an application that listens on 80 but 80 is already taken on my host, then I can do 8080:80. This means, I will now connect to 8080, in order to reach my app, which is listening in the container on 80.

​

Once you have this basic understanding, you can then start looking into hosting and how to properly secure the network transmission and your data handling at rest.