Deploy Ultraviolet Proxy on Replit, Railway & Docker — Step-by-Step 2026

Why Hosting Matters for Ultraviolet Proxy

Public ultraviolet proxy instances go offline constantly — schools and ISPs update their blocklists weekly. Running your own instance on a platform you control gives you a persistent, private URL that stays unblocked far longer than shared links. The platforms covered here are all either free or extremely low cost, making self-hosting a realistic option even without a dedicated server.

Ultraviolet Proxy on Replit (repl.co)

Replit is the most beginner-friendly option for deploying an ultraviolet proxy repl. The platform runs Node.js out of the box, requires no local installation, and gives you a public HTTPS URL the moment your repl starts.

Step 1 — Create the Repl

Go to replit.com and sign in. Click + Create Repl and choose the Node.js template. Name it anything — your URL will be https://your-repl-name.your-username.repl.co once deployed.

Step 2 — Import the Ultraviolet-App Repository

Instead of using the Node.js template directly, click Import from GitHub and paste the URL of the Ultraviolet-App repository. Replit clones the repo and detects the package.json automatically. It will install dependencies on the first run.

Step 3 — Set the Run Command

In the .replit config file (or the Run button settings), set the run command to npm start. This launches the Express server bundled with the bare/wisp backend that Ultraviolet needs.

Step 4 — Test Your Ultraviolet Proxy Repl

Click Run. Replit opens a webview on the right. Enter any URL in the proxy bar — if the site loads, your ultraviolet proxy repl.co instance is live. Copy the webview URL; that is your public proxy address.

Keeping the Repl Alive

Free Replit accounts sleep repls after roughly 30 minutes of inactivity. Use UptimeRobot (free tier) to ping your repl URL every 5 minutes. Add a simple /ping health-check route to your Express server that returns HTTP 200 — this keeps the ultraviolet proxy replit instance awake without loading pages.

Ultraviolet Proxy on Glitch

Glitch is another browser-based Node.js host popular in the proxy community. The ultraviolet proxy glitch setup follows a nearly identical pattern to Replit, but with a different file editor interface.

Click New Project → Import from GitHub and paste the Ultraviolet-App repo URL. Glitch installs dependencies from package.json automatically. Your project runs at https://your-project-name.glitch.me — a public HTTPS URL suitable for use as a proxy.

Glitch's free tier sleeps projects after 5 minutes of inactivity, which is more aggressive than Replit. The UptimeRobot ping strategy works here too. One key difference: Glitch limits projects to 4,000 hours of uptime per month on the free plan, so heavy traffic may exhaust the quota. For personal use it is more than sufficient.

Ultraviolet Proxy on Railway

Railway offers a more reliable free tier for ultraviolet proxy railway deployments. Unlike Replit and Glitch, Railway does not sleep services automatically — your proxy stays online 24/7 within the free tier's 500 execution-hour monthly cap.

Deploying to Railway

Sign in to railway.app with your GitHub account. Click New Project → Deploy from GitHub repo and select your fork of Ultraviolet-App. Railway auto-detects Node.js and runs npm start by default. Within two minutes your deployment is live at a .railway.app subdomain.

Setting Environment Variables

In the Railway dashboard, go to your service's Variables tab. Add PORT=8080 if your application hardcodes that port, or let Railway inject the PORT variable dynamically by reading process.env.PORT in your index.js. This is the single most common reason an ultraviolet proxy railway deployment fails to start.

Custom Domains on Railway

Railway lets you attach a custom domain for free. Go to Settings → Domains, add your domain, and update your DNS CNAME record. A custom domain helps longevity — schools block railway.app subdomains before they block unknown domains.

Ultraviolet Proxy with Docker

Docker deployment is the most flexible option for advanced users who want to run an ultraviolet proxy docker container on any infrastructure — a home server, a cloud VM, or a Kubernetes cluster.

Writing a Dockerfile for Ultraviolet

Create a Dockerfile in the root of the Ultraviolet-App project:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 8080
CMD ["npm", "start"]

The Alpine base image keeps the ultraviolet proxy docker image under 150 MB. Using npm ci instead of npm install produces deterministic, faster installs suitable for CI pipelines.

Building and Running the Container

docker build -t ultraviolet-proxy .
docker run -d -p 8080:8080 --name uv-proxy ultraviolet-proxy

The -d flag runs the container in detached mode. Access the proxy at http://localhost:8080. Combine with Nginx on the host to add HTTPS via Let's Encrypt — service workers require HTTPS for production use.

Docker Compose for Multi-Service Setup

If you want to run the static frontend and bare server as separate containers, a docker-compose.yml file lets you orchestrate both services with a single docker-compose up -d command. The bare server exposes WebSocket connections and the frontend serves static files; an Nginx service acts as the reverse proxy between them. This mirrors the split ultraviolet static proxy architecture discussed in the setup guide.

Platform Comparison at a Glance

Replit: Easiest to start, sleeps on inactivity, free. Best for testing and light personal use.
Glitch: Similar to Replit, slightly more aggressive sleep policy, 4,000-hour monthly cap.
Railway: No automatic sleep, 500 execution-hours free, best free-tier reliability. Recommended for a persistent ultraviolet proxy.
Docker: Full control, runs anywhere, requires a VPS or home server. Best for performance and privacy.

Security Considerations for Public Deployments

If you make your ultraviolet proxy repl or Railway deployment public, understand that anyone with the URL can use it. Consider adding basic HTTP authentication to restrict access, or keep the URL private and share it only with trusted users. Never log user traffic — not only is it a privacy violation, but stored logs increase legal risk if your instance is misused.