# screego/server: WebRTC screen sharing you host yourself > Screego is a Go server that shares screens over WebRTC with an integrated TURN service, aimed at developers who need readable code on the other end. It installs as a single binary or Docker image, but it is not a meeting tool. **screego/server** — screen sharing for developers https://screego.net/ - Repository: https://github.com/screego/server - Website: https://app.screego.net - Stars: 10,713 · Forks: 737 - Language: Go - License: GPL-3.0 - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/screego-server ## The problem screego was written to solve The README opens with a first-person account: sharing a screen over corporate chat tools like Microsoft Teams produced a stream that lagged several seconds behind, or quality so poor that colleagues could not read the code, or both. That is a specific failure mode. Text is high frequency detail, and general purpose conferencing encoders are tuned for faces and motion, so they spend bitrate where a code editor gains nothing. Screego targets exactly that gap. The stated scope is narrow on purpose: it is "an addition to existing software and only helps to share your screen. Nothing else". So the audience is developers, and the use case is showing a terminal, an editor or a browser to a handful of people who need to read it. It is not a replacement for a meeting product and the README does not pretend otherwise. Multi user screenshare is listed as a feature, which means several people can present into the same room rather than one broadcaster and a passive audience. ## How WebRTC and the bundled TURN server fit together The repository layout shows the split clearly. There is a router/ directory, a ws/ directory for WebSocket handling, a turn/ directory, an auth/ package, a users directory, and a ui/ front end. The Go module file lists github.com/pion/turn/v4 and github.com/gorilla/websocket among the direct dependencies, which tells you the transport story without guessing: signalling and control messages travel over a WebSocket connection, and the media itself is negotiated as WebRTC between browsers. That matters because WebRTC peers cannot always reach each other directly. When both sides sit behind NAT, the connection needs a relay, and screego ships the TURN server inside the same process instead of asking you to stand up coturn next to it. The README links a NAT Traversal page under its own documentation and lists "Integrated TURN Server" as a feature. The practical consequence appears in the Dockerfile, which exposes 3478/tcp, 3478/udp and 5050. Port 3478 is the standard TURN port, and 5050 is the application port. If you deploy behind a firewall and forget the UDP half of 3478, direct connections may still work on a friendly network and fail on a hostile one, which is the kind of bug that shows up only for the colleague on hotel wifi. Auth sits in its own package and a users file exists at the repository root, so access control is part of the server rather than delegated to an external identity provider. The README does not describe the auth model in detail, and the configuration reference lives on the documentation site rather than in the repository README. ## Installing screego and starting the server The README points to two installation paths: Docker and a single binary. The Dockerfile is minimal, built FROM scratch with USER 1001, which means the container runs unprivileged and carries no shell. That is a deliberate choice and it also means you cannot exec into the container to debug; you read logs from the outside instead. The image expects the binary at /screego, sets WORKDIR to "/", and defaults to the serve command via CMD. The exposed ports are declared in the Dockerfile itself: ```dockerfile EXPOSE 3478/tcp EXPOSE 3478/udp EXPOSE 5050 ``` After that, the web interface answers on port 5050. If you build from source instead, the repository ships screego.config.example and screego.config.development at the root, and the module declares go 1.26.0, so a Go toolchain at that version or newer is the starting point. The example config is the file to copy before first run; the README itself does not walk through every key, and the configuration page on screego.net is where the project documents them. ## Where screego stops being the right tool The README is unusually honest about the boundary: screego only shares screens. There is no mention of recording, chat, file transfer, whiteboarding, calendar integration or persistent rooms. If your team needs a session that can be replayed later, or a shared document that outlives the call, this is the wrong product and adding those features is not a configuration change. The second limitation is operational. Because the TURN server is integrated, the relay traffic lands on the same host as the application. A self-hosted screego instance on a small VPS that suddenly carries several concurrent high resolution streams is pushing media through that machine, and the README makes no capacity claim at all. There is no documented sizing guidance in the repository README, so treat the box you deploy on as a variable you have to watch rather than one the project has solved for you. Third, the deployment model assumes you can expose ports 3478 and 5050 to the public internet. Teams that can only publish a single HTTPS endpoint through a locked-down ingress will find the TURN requirement awkward, because TURN over TCP and UDP is not the same thing as proxying an HTTP route. ## screego compared with a general purpose conferencing stack The obvious alternative is the software the README says motivated the project: Microsoft Teams, or any conferencing tool built around meetings rather than screens. The difference is not quality settings. A conferencing product negotiates a session between participants and applies an encoder tuned for camera video, with the screen share treated as one input among several. Screego has no camera pipeline to balance against, so the share is the whole session, and the WebRTC connection is established directly between browsers with the bundled TURN server as the fallback path. The trade is scope for control. With Teams you get scheduling, chat, recording and identity management, and you accept whatever the encoder decides your code looks like. With screego you get a binary, a config file and a room, and you own the network path. If your problem is "my colleagues cannot read my code", the second trade is the one that addresses it. If your problem is "we need a meeting with minutes and a recording", screego does not enter the conversation. ## Maintenance, releases and the GPL-3.0 licence The last push to the default branch was on 2026-08-20, the same day v1.12.5 was tagged, and the repository is not archived. Release cadence in the visible history is uneven: v1.12.3 arrived on 2026-04-25, v1.12.4 on 2026-05-13, and v1.12.5 on 2026-08-20. The project follows SemVer, so patch releases should be drop-in for a running instance, and the single binary model means an upgrade is a container pull or a binary swap plus a restart. There is no database migration story to worry about in the repository layout, though the users file and any auth state should be backed up before you replace the binary. The licence is GPL-3.0. That is a copyleft licence, and it matters if you plan to modify screego and distribute the result or offer it as a network service to others. Running an unmodified instance internally is a different situation from shipping a fork. This is not legal advice; read the licence text in the repository and talk to counsel if you intend to redistribute or build a hosted product on top of the code. ## Frequently asked questions The questions below cover the points a new operator hits first: what the project actually does, how it installs, and what it will not do. ## Conclusion Adopt screego if you need to show code to a few people at readable resolution and you can run one binary with a TURN port open. Skip it if you need recording, chat, file transfer or anything resembling a meeting suite, because the README states it only helps to share your screen. Before rolling it out, confirm that the ports from the Dockerfile (3478/tcp, 3478/udp, 5050) are reachable from outside your network and that your reverse proxy forwards WebSocket upgrades, since the UI depends on them. ## FAQ ### What is screego/server and who is it for? It is a self-hosted screen sharing server for developers, written in Go, that transfers the stream over WebRTC. The README describes it as an addition to existing software that only helps to share your screen. ### How do I install screego/server? The README lists two paths: Docker or a single binary. The Dockerfile exposes ports 3478/tcp, 3478/udp and 5050 and runs the binary with the serve command. ### Does screego/server need a separate TURN server? No. The README lists an integrated TURN server as a feature, and the Go module depends on github.com/pion/turn/v4, so the relay runs in the same process as the application. ### What licence does screego/server use? The repository is licensed under GPL-3.0. That is a copyleft licence, so redistributing a modified version carries obligations that running an unmodified instance internally does not. ### Which ports does screego/server use? The Dockerfile exposes 3478/tcp and 3478/udp for TURN, and 5050 for the application. Both halves of 3478 matter if participants are behind NAT. ## Sources - [License: GPL-3.0](https://github.com/screego/server/blob/master/LICENSE) - [Project website](https://app.screego.net) - [README](https://github.com/screego/server/blob/master/README.md) - [Releases](https://github.com/screego/server/releases) - [screego/server on GitHub](https://github.com/screego/server) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/screego-server