dogeub packs tools and a browser proxy into one Node server that will not fit on Vercel

One page that collects tools, apps and entertainment

dogeub is described in the repository as a versatile internet hub. The README states the point of the project plainly: to eliminate the need to search multiple websites for different things by packing together tools, apps, as well as entertainment and private browsing, all in one place. The target audience is stated just as plainly, people who want a hub containing everything they need to enjoy the internet.

The content is community driven. The README says many of the tools, apps and entertainment are requested through the Discord community or added through pull requests, and it recommends making pull requests to contribute. The homepage field points at a Discord invite rather than a documentation site, which reflects where the project actually coordinates.

There is a stated editorial line too. A caution block says the project does not include illegal, piracy or copyright infringing tools or apps. Worth knowing, because a hub of this kind is exactly the sort of project where that question comes up, and the answer is documented rather than implied.

The repository topics list apps, browser, games, hub, internet-hub, service, tools, trending and trending-repositories, so there is a trending repositories element alongside the curated links.

The private browsing layer is a proxy stack, not a VPN

The interesting engineering in dogeub is the private browsing part, and it comes from elsewhere. The README credits MercuryWorkshop/wisp-server-node, MercuryWorkshop/scramjet and titaniumnetwork-dev/Ultraviolet among the libraries that make the project possible, and the package.json shows how they are pulled in.

The runtime dependencies include @mercuryworkshop/wisp-js, @mercuryworkshop/libcurl-transport, @mercuryworkshop/scramjet and @mercuryworkshop/bare-as-module3, plus @titaniumnetwork-dev/ultraviolet. On top of that there is bare-mux-fork, and the scramjet and bare-mux packages are pinned to specific release tarballs rather than version ranges.

What that stack is, concretely, is a proxy that runs in the server process. Ultraviolet and the wisp stack are the pieces that let a request be forwarded rather than answered locally, and the bare-server packages provide a minimal Node runtime with the multiplexed protocol those need. The libcurl transport and the tarball pinning suggest the project depends on exact protocol compatibility between those layers, which is a maintenance consideration rather than a detail.

Calling it private browsing rather than anonymity is accurate. It is a proxy path for the pages the hub links to, running on your own machine, not a claim about identity, location or the absence of logging on the sites you reach.

It is a React and Vite frontend on a Fastify server

The stack is visible in package.json. The frontend is React 19 with react-dom and react-router-dom, built by Vite with the React SWC plugin, styled with Tailwind CSS 4 and postcss, and state handled by zustand. Icons come from lucide-react.

The server is fastify 5, with @fastify/compress, @fastify/cookie and @fastify/static as plugins, plus cookie-parser and dotenv for configuration. There is also @fastify compression for responses, jszip for working with zip archives, nprogress for progress indication and react-ga4 for analytics.

The scripts are minimal: dev runs vite, build runs vite build, lint runs eslint over the project and preview runs vite preview. The package is marked private, which is correct for an application rather than a library, and the version field reads 5.0.42.

The project name in package.json is v5-react-2, a leftover from the template lineage that nobody renamed. It is harmless, but it is the kind of thing that shows up in your lockfile and in any tooling that reads the name.

The top level of the repository also holds a server.js, a render.yaml for the Render platform, a Dockerfile, copy.env for configuration, masqr.js, a Checkfailed.html page and index.html, alongside the src/ and public/ directories.

Running it locally, and the Vercel warning in the README

The README is explicit that this project will not work on Vercel, and it gives the reason: dogeub runs a custom Node server while Vercel only supports serverless functions and does not allow persistent Node servers. That warning matters for anyone who reaches for a hosting platform first.

For production, the sequence is a clone, an install, a build and then running the server directly.

git clone https://github.com/xorynix/dogeub.git
cd dogeub
npm i
npm run build
node server.js

For development, the same three steps end with the Vite dev server instead.

git clone https://github.com/xorynix/dogeub.git
cd dogeub
npm i
npm run dev

The difference matters operationally. In development you get Vite's hot reloading and the frontend served by Vite, while in production the built assets are served by the Fastify server in server.js. Anything that behaves differently between the two is worth testing in the production mode, since that is what a deployed instance runs.

Because the whole thing is a Node server, the deployment target is a container or a small VM, and the persistent server is the reason the Vercel note exists.

Docker, the port 3000 convention and the TLS requirement

The container image is published on GitHub Container Registry and the README gives the run command with a restart policy and an explicit port mapping.

docker run -d \
  --name dogeub \
  --restart unless-stopped \
  -p 3000:3000 \
  -e NODE_ENV=production \
  -e PORT=3000 \
  ghcr.io/xorynix/dogeub:latest

Port 3000 is the convention throughout. The Dockerfile sets NODE_ENV and PORT in the runtime stage, with a comment noting that dogeub documents PORT via env in copy.env, and it exposes 3000 and starts the server with node server.js.

The Dockerfile is a two stage build. The build stage uses a full node:20-bookworm image, installs dependencies with npm ci against the copied package files so the layer is cached, copies the source and runs npm run build. The runtime stage is node:20-bookworm-slim, installs only production dependencies with npm ci --omit=dev, and copies in just the dist directory, the public directory, server.js and a few optional root files.

The container runs as the node user rather than root, which is the right default and is called out in a comment.

The one deployment requirement is easy to miss. A note in the README says that if you access over a network instead of localhost, you need to provide a valid SSL certificate, for example with a reverse proxy such as Nginx or Caddy, and that this is required for the built-in service worker to function properly. A service worker will not register on a plain HTTP origin, so without a certificate the private browsing feature quietly does not work even though the rest of the hub does.

AGPLv3 is the licence to read before you expose it

The licence is AGPLv3, stated in the README and with the full text in the LICENSE file. That is the most consequential fact in this project for anyone thinking beyond their own machine.

The AGPL is a copyleft licence with a network clause, so if you modify the project and then offer the modified version to users over a network, you are required to offer those users the corresponding source of your modified version. For a self hosted hub that only you use, this does not bite. For a hub that a group, a community or a public audience uses, it is the part of the licence that needs reading carefully, and this is a description of how the licence is structured rather than legal advice.

There is also a content consideration, and the README handles it explicitly. A caution block states that although this is an internet hub, the project does not include illegal, piracy or copyright infringing tools or apps. For a self hosted aggregator of links and tools, that is the kind of statement that has to be in the documentation rather than assumed, and it means the responsibility for what gets added sits with whoever runs the instance and with the contributors.

The Docker image is distributed under the same terms as the source, so the container does not create a separate licensing position.

Maintenance, releases and what the repository does not say

On maintenance, the repository is not archived and the last push was on 2026-05-03. There are no GitHub releases, so there is no tag to pin and no release notes to read for a given version. The version field in package.json reads 5.0.42, which is the number to track if you want to know what a checkout contains.

The absence of releases is a bit odd for a project that ships a container image, because the image is tagged latest, and a rolling tag plus a moving main branch means an update to the image can change what you are running without any version marker in your own logs. If you deploy this, pin the image digest or the tag you tested rather than relying on latest.

The documentation is thin. The README covers building, deploying and the private browsing requirement, and links to a Discord for everything else. There is no separate documentation site, no configuration reference beyond the copy.env file, and no changelog file in the top level listing.

The code quality tooling is present, though. eslint.config.js is in the repository along with a prettier configuration, a tailwind config, a postcss config and a vite config, and the dev dependencies include the bundle obfuscator plugin, which suggests an interest in shipping a harder to read bundle. The README also links a contributors graph and a Star History chart for the project.

Editorial conclusion

Adopt dogeub if you want a single self hosted page that collects web tools, apps and entertainment, and you are prepared to run a persistent Node server with a reverse proxy in front of it for TLS. Do not adopt it if you need a serverless deployment, since the README states it will not work on Vercel, and read the AGPLv3 terms before you expose it to a group of users. Before you deploy, put Nginx or Caddy in front of it for a valid certificate because the built-in service worker needs one, and read copy.env to see which settings the server expects.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. xorynix/dogeub on GitHub