That has the daemon running that podman avoids. Be carefully what you do with it or expose it to on the internet. Sorry for wasting the time of responding

I understand Docker can be confusing, especially if you're not a developer. Docker was developed to solve the problem of "it works on my computer" (but not yours), meaning it is meant to behave the same regardless of where it is installed. It does this by carrying all its dependencies with it. How well it succeeds in solving the problem is up for debate and I'm not here to debate the merits of Docker anyway.

I would say two things: don't get discouraged:; it has a learning curve. And conversely: don't think Docker solves everything, either. Understanding how it works and what it can do is your best bet at using it successfully or even deciding that your use case is not right for it.

I'm not familiar with Otter wiki (just heard about it today in this thread), but I will go by the online docs and see if I can help you get going. Going by the docker compose instructions, the example shows this compose file:

services:
  otterwiki:
    image: redimp/otterwiki:2
    restart: unless-stopped
    ports:
      - 8080:80
    volumes:
      - ./app-data:/app-data

The two last lines are key: the volumes section. The first and only entry maps a local directory ./app-data outside the container through a bind mount, to the path /app-data (note the leading slash) inside the container. It is mapped by default read-write, so the container can write to the directory. You can also read/write from the host side and put files you want in there.

The files here are only stored in that one place (i.e., not copied), so if you want backups you need to take care of that separately.

For your use-case, it may be enough to use the customization instructions for Otter wiki. Notice how their customized docker compose file has a second volume in it. In their example, you would put additional files into the ./custom directory on the host. It works the same as the app-data volume.

That takes care of just running the application, but what if you wanted to customize it more? That is where you need to use the source and git. I am going to just use a fictional example app for this, because Otter wiki app may have some extra steps that can make it confusing. Basically what you want to do is clone the git repo of whatever you're building:

git clone https://github/whatever

Now you have the source. You can add files, make code changes, whatever. And once you're done with that you will use git as usual and commit the changes, push it to your branch, and maybe open a PR to the original repo. That's not important for Docker.

The next thing you do is build the Docker image. Many people confuse Docker images and containers, but on short: the image is like the file system for the container, and the container is an instance of that file system + processes running on a Docker host. Many containers can run the same image on the same host and in fact that is how you horizontally scale an application.

Once you have the image, you can just run it locally, or you can push it to a registry. Here is how you would do that:

# Build the local image in the context . (current directory) and tag it as my-cool-app with tag latest
# This uses the instructions in the Dockerfile to build the image. It can run commands, copy files, etc.
docker build . -t my-cool-app:latest 
# ...lots of messages...

# Run the app - press control-C to stop it
docker run --rm -it my-cool-app:latest 

If you want to push it to Docker hub or another registry:

# Tag the image with the repo name in front
docker tag my-cool-app:latest registry.example.com/myuser/my-cool-app:latest 
# Push the image to the registry
docker push registry.example.com/myuser/my-cool-app:latest  

One thing to keep in mind here is do not include any secrets with the image. If you do, anyone who can download the image can read them, because they get baked in with it.

Let me know if you have any other questions and I'll be happy to answer.

not to distribute server applications to end users, but to be used by developers who need a reproducible environment,

What? No. It's extremely suited to be used as a server for client applications. I think you might want to learn a great deal more about docker before you come to that conclusion.

Use bind mounts instead of named volumes for persistent data and it's a lot more predictable to use like you want.