Thanks for opening this PR! 🙌

I had a quick high-level look, and I like the idea and the direction you’re taking here. I won’t be able to do a full review today, but I’ll go through it in detail in the next couple of days.

Thanks for opening this PR! 🙌

I had a quick high-level look, and I like the idea and the direction you’re taking here. I won’t be able to do a full review today, but I’ll go through it in detail in the next couple of days.

One thing missed is context path in workflow file.
Also keep in mind you need to tag a new version for the pipeline to build.

Image is available on ghcr.io/bitwister/tun:latest for now.

Sorry for the delay — I’ve been quite busy with other work, but I’ll do my best to review the pull request by the end of this week 💪

Hi again👋

Thanks for the contribution!

I’m wondering — what’s the purpose of introducing this Dockerfile/image that sets up tun inside the container? In docker-compose, we can simply use network_mode: "service:xraytun" to route other services traffic through the VPN container, without an additional image. Could you clarify what problem this image is solving and what advantage it brings compared to using network_mode?

Hi again👋

Thanks for the contribution!

I’m wondering — what’s the purpose of introducing this Dockerfile/image that sets up tun inside the container? In docker-compose, we can simply use network_mode: "service:xraytun" to route other services traffic through the VPN container, without an additional image. Could you clarify what problem this image is solving and what advantage it brings compared to using network_mode?

Its all about preserving network container isolation, service:xraytun simply breaks network isolation and makes big configs unreadable and unmanageable

You can use this docker image with either approaches, but if you want to learn more about how twine works and why its created I've already did my job explaining it in the repository's README.
This question is a bit irrelevant to having docker image of xraytun to begin with.

After careful consideration, and sorry for the long delay in responding, I've decided not to include Docker support in this repository directly.

The primary goal of this program is to provide a clean, native VPN solution without GUI dependencies. Dockerization represents a relatively niche use case that users can implement on their own if needed.

If someone requires running the application in a container environment, they can easily create a minimal Dockerfile using alpine or scratch base images. I prefer to avoid maintaining additional Docker infrastructure. The current focus remains on developing and enhancing the core functionality for native usage scenarios.

As a compromise - I've included your proposal into README.md, referencing this issue.