DEV Community: S.S.Vikash

My Experience with college server.

S.S.Vikash — Thu, 21 Aug 2025 17:21:54 +0000

Hello people!

Ever felt the pain of wanting to deploy a side project but getting bogged down by cloud configs, billing alarms, and complex DevOps tools? So did I. That's why I built KWS.

But this isn't just a story about an application. It's a story about taking that application from a codebase on my laptop to a physical server humming in a college rack, navigating network policies, and building a real-world, self-hosted cloud platform. Buckle up!

🚀 What is KWS?

KWS is a self-hosted cloud platform that lets developers and students deploy their apps in secure, containerized environments instantly. Think of it as a mini-Heroku + VS Code Server + Fly.io, all running on your own hardware.

Here’s what it offers:

🔒 Secure VPN-Based Access: Every container is isolated and accessible via a private WireGuard VPN.
💻 Browser-Based VS Code: Every instance gets a live VS Code IDE at https://<container-id>.kwscloud.in. No setup needed.
🗃️ Built-In PostgreSQL: Managed databases from the dashboard with scoped user privileges. No need to run DBs in your app container.
🌐 One-Click Public Hosting: Make your app public in seconds at https://<your-app>.kwscloud.in. No manual Nginx configs!
🧰 Full Instance Control: Start, stop, redeploy, and monitor everything from a clean dashboard.

It's perfect for hackathons, college courses, or anyone who wants real deployment power without the cloud bill.

🏗️ The Adventure: Hosting KWS on College Hardware

Our college bought a new server for KWS. The mission was simple: get it from the box to the internet. The execution, however, was a fantastic lesson in practical networking.

Step 1: The Hypervisor - My Foundation

I started with bare metal. I chose Proxmox VE (a fantastic Type 1 hypervisor) as my base layer. It allows me to create and manage virtual machines (VMs) easily, giving me the flexibility to host KWS and other future services.

Step 2: Navigating the Network - The DMZ

This was the first big lesson in enterprise IT. You can't just plug a server into the main campus network.

The Problem: The main LAN is trusted. A vulnerable server on it could risk the entire college network.
The Solution: The DMZ (Demilitarized Zone), a segregated network for public-facing services. The college's firewall strictly controls traffic between the DMZ, the internet, and the internal LAN.

The college assigned me a private IP from the DMZ range (like 10.10.20.x) for my Proxmox host. They then set up firewall rules on their edge device to NAT and forward public traffic for ports 80, 443, and 51820 (WireGuard) to my Proxmox host's DMZ IP.

Step 3: The Internal Challenge - No DMZ IPs for VMs

Here's where it got interesting. The college's policy prevented me from getting additional DMZ IPs for our individual VMs. I had to get creative.

My Solution: Create a private network inside Proxmox for all our VMs.

I created a new Linux Bridge (vmbr1) in Proxmox and gave it its own private subnet: 192.168.69.0/29.

Why a /29? It provides 6 usable IP addresses. One for the Proxmox gateway, leaving five for VMs. It's small, secure, and perfect for my needs.

# /etc/network/interfaces on Proxmox
auto vmbr1
iface vmbr1 inet static
    address 192.168.69.1/29 # Proxmox is the gateway
    bridge_ports none
    bridge_stp off
    bridge_fd 0

Step 4: Making the Magic Happen with iptables

Now I had a problem. My KWS VM (and others) lived on the 192.168.69.0/29 network, utterly invisible to the outside world.

The solution? Turn the Proxmox host into a router.

1. Enable IP Forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl -p

2. Set up NAT (Masquerading) so the VMs can access the internet outbound:

iptables -t nat -A POSTROUTING -s 192.168.69.0/29 -o vmbr0 -j MASQUERADE

3. Set up Port Forwarding (DNAT) to direct public traffic to the correct internal VM. This was the key to making KWS accessible.

HTTPS:

iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to-destination 192.168.69.2:443
iptables -A FORWARD -p tcp -d 192.168.69.2 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Wireguard VPN:

iptables -t nat -A PREROUTING -i vmbr0 -p udp --dport 51820 -j DNAT --to-destination 192.168.69.2:51820 

iptables -A FORWARD -p udp -d 192.168.69.2 --dport 51820 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

4. Make the rules persistent:

apt install iptables-persistent
iptables-save > /etc/iptables/rules.v4

Step 5: The Grand Finale - Wildcard SSL

The main domain for the college is kamarajengg.edu.in, and it already has a wildcard SSL (*.kamarajengg.edu.in). This allows kws.kamarajengg.edu.in to work with HTTPS. However, apps like app1.kws.kamarajengg.edu.in cannot get HTTPS because wildcard certificates only support one level, and these are subdomains of a subdomain.

To solve this, I purchased my own domain kwscloud.in, set up a DNS challenge in Cloudflare (where my DNS is managed), and obtained a wildcard SSL (*.kwscloud.in). Now, apps hosted in kws.kamarajengg.edu.in are securely accessible under *.kwscloud.in.

📖 The Architecture Diagram:

Here’s a simplified view of how traffic flows to a user's app:

🎓 Lessons Learned & Conclusion

This project was an incredible deep dive into practical networking, security, and system administration. I learned:

The Value of the DMZ: Isolating public services is a critical security practice.
NAT and Port Forwarding are Foundational: Understanding iptables is like gaining a networking superpower.
Planning is Key: Carefully planning your IP addressing scheme from the start prevents headaches later.
The Power of Self-Hosting: There's immense value in controlling your own infrastructure, both for learning and for independence from cloud vendors.

O(1) IP allocator regardless of the network size.

S.S.Vikash — Mon, 16 Jun 2025 18:32:05 +0000

An IP allocator that dosen't care about the network size, or active hosts in the network. If a client requests for a free IP, it will find it in O(1) time. Sounds cool? It's actually dead simple.

Let's first understand my use-case. I am building a vpn secured IaaS using wireguard (open source vpn protocol)

The problem:
Wireguard is not a server-client based one. It's p2p. So, there is no concept of IP allocation in the server side of wireguard in a logical sense. So, I had to write one myself.

Naive Solution:

The naive approach would be looping through the entire network host portion and finding a free one. But that would take ages. Imagine a network of /8 which has more than 16 million hosts.
So, I had to think something better.

O(1) Solution:

I already have a db table where I would store all the public keys and IP's of wireguard peers. But I can't loop over them all to find a free one.
So, I brought redis stack in. For a simple reason. To push and pop released IP's. Clients may remove their device from the network. In that case, their released IP will be stored in the redis stack.
So now, if a user requests for a new IP, I would first check if there are any released IP's in the redis stack. If it's not empty, I'll just pop it which is O(1) in time complexity.
If there are no released IP's in the redis stack, I would then query the DB to get the max IP there is currently and increment that with 1 to get the next free IP.

New problem:

But now you can see a new issue rising up. Query the DB to get the max IP? How? If you store the IP as a literal string like "10.0.0.1/16" or "10.1.0.0/8", it would be too difficult to parse the string and find the current maximum one.

Solution:

A simple solution. Don't store the IP as a literal string. Store it as a number. What? How?
For example, lets take /24 IP addresses as an example. (10.0.x.x)
If the number is 255, then the equivalent IP is 10.0.0.255. If the number is 256, then the equivalent IP is 10.0.1.0, and so on. I hope you can get the idea.
It would be super easy to get the maximum of a number from a DB table.
Now, I just have to write a function that converts the number to the IP equivalent regardless of the CIDR notation.
I'll share my implementation using basic math operations.

Code that converts the number to IP equivalent:

func (ip *IPAllocator) GenerateIP(hostNumber int) (string, error) {
    firstOctet, secondOctet, thirdOctet := 0, 0, 0

    if ip.CidrValue > 24 || ip.CidrValue < 8 || ip.CidrValue%8 != 0 {
        log.Println("Cannot generate IP for this cidr. Only supports /24, /16, and /8")
        return "", errors.New(status.INVALID_CIDR)
    }

    c := hostNumber / 256

    if c < 256 {
        thirdOctet = hostNumber % 256
        secondOctet = c
        return fmt.Sprintf("10.%d.%d.%d", firstOctet, secondOctet, thirdOctet), nil
    }

    firstOctet = c / 256
    secondOctet = c % 256
    thirdOctet = hostNumber % 256

    return fmt.Sprintf("10.%d.%d.%d", firstOctet, secondOctet, thirdOctet), nil
}

Now, we have one last problem. It's still not truly O(1) because the DB query to get the maximum number will be O(N)
The simple solution is to index the column that has the number

Now, the DB query would be something like this.
SELECT ip_address FROM wgpeer ORDER BY ip_address DESC LIMIT 1
where ip_address is the indexed column.

The magic lies behind how sorting with index works.
Indexing a column will make the db to create a B+ tree.
So, if I sort the column with limit 1 and DESC, it will do a backwards index scan which will start from the rightmost leaf node and that is obviously the highest value. It will stop just right there as we have LIMIT 1.
And this ultimately makes the entire query O(1)

Conclusion:

Redis push and pop: O(1)
DB query : O(1)
number to IP : O(1)
And ultimately the entire logic of the IP allocator becomes O(1)

Code execution system..

S.S.Vikash — Mon, 07 Apr 2025 13:01:44 +0000

🚀 Designing a Secure & Scalable Code Execution System (Like Online Compilers)

So, for the past week, I’ve been designing and building my own code execution system from scratch — similar to what online compilers do — for my application.

😅 The Wrong Way I Started With

My initial prototype had a simple idea:

Clients send code to a gateway endpoint.
The gateway calls the code execution service.
The code execution service spins up a new process (e.g., Python) and runs it.
The gateway synchronously waits for the response and returns it to the client.

❌ Sounds simple, but it was a disaster waiting to happen...

🚨 1. Scalability Nightmare

Let’s say 10,000 Python requests come in.

That’s 10,000 new processes created.
Each process might compute something heavy (e.g., big factorials).
CPU and RAM go 📉.
And worse: 10,000 clients are left waiting — even the homepage won’t load.

🔐 2. Security Disaster

When you execute user-submitted code directly on your host machine:

You're practically inviting hackers.
They can run anything — install backdoors, shut down your server, leak environment variables, etc.
No isolation between your service and their malicious code.

🛠️ Time to Re-Architect

I took a step back and decided to redesign the entire system. The core idea was to:

✅ Make it asynchronous

✅ Make it secure and isolated

✅ Make it scalable

⚙️ System Architecture Overview

Instead of waiting for the code to execute:

The gateway receives the code and publishes a job to a RabbitMQ queue.
It returns a unique Job ID to the client immediately.
The code execution service listens to the queue and picks up jobs.
Code is run in Docker containers (isolated environments).
Output is sent back through another queue.
The client connects to an SSE (Server-Sent Events) endpoint to receive output in real-time.

🧠 Container Management & Scheduling

I didn’t want to bring in Kubernetes or Docker Swarm — too heavy for my use case. So I built:

A custom scheduler (event-driven)
A pool of pre-warmed containers (5 per language)
A thread-safe internal queue (per language)
A linked-list implementation to manage the job queues

🧪 When a job comes in:

It’s placed into its corresponding language queue.
My scheduler detects available containers and assigns the job.
When the job completes, the output is sent to RabbitMQ and then streamed to the client via SSE.

🔐 Defense Against Attacks

Because code execution endpoints are prime targets, I added:

✅ Rate Limiting

Implemented a token bucket algorithm
Limits how many requests a user can make per second

✅ Execution Timeout

Every container has a 5-second timeout
Prevents infinite loops and long-hanging processes

✅ Isolated Environments

Every job runs inside a Docker container
Malicious code can’t touch the host machine

⚡ Advantages of This Architecture

🛡️ Secure execution using isolated Docker containers
🔄 Asynchronous and non-blocking — no user is left waiting
🚀 Scalable — containers are reused and jobs are scheduled
🔒 Resilient to attacks like infinite loops, backdoors, and DOS

🎥 I Made a YouTube Video Too

I shared the system design and architecture (not the source code).

It walks through the architecture visually so others can learn from it.

🧠 Final Thoughts

This system took me about a week to plan and build. And I took my time because…

“Unlike typical APIs where attackers have to find vulnerabilities, a code execution API is an open playground for hackers. You're basically letting them run anything.”

So I had to make sure the design was secure, scalable, and robust.

🙌 Let Me Know Your Thoughts!

If you're interested in the code behind this or want me to deep dive into:

🧠 My custom scheduler algorithm
🧱 Linked list queue implementation

Let me know in the comments! 💬

💻 Built with:

Go (Golang)
RabbitMQ
Docker
Custom scheduler (Golang)
SSE

PHP and Go as a Tech Stack.

S.S.Vikash — Wed, 25 Dec 2024 14:27:42 +0000

First, let me start with all the reasons why I prefer this over other famous JAVASCRIPT tech stacks..

I hate "Javascript for everything" trend.. Yea.. Javascript can do pretty much anything at this point.. BUTT, is it effective in doing that?
Let's take an example of a very intensive CPU bound task. This is a code sample that simulates CPU intensive task. And let's see how Javascript performs.

Reason 1: Javascript sucks at CPU bound tasks!

setTimeout(function() {
    console.log("Hello world")
}, 1000)

const startTime = Date.now();
while (Date.now() - startTime < 3000) {} //Simulating a long CPU intensive main thread task..

console.log("End")

So, what do we have here? Me, as a user of JAVASCRIPT would expect to see "hello world" printed out after 1 second.. And guess what. It dosen't. It spits out "hello world" after 3 seconds..
Why does this happen? To understand this, we need to understand how event loop in browsers and node js works. In simple terms, the event loop checks the call stack and the callback queues at the same time. The callback function that we pass in the setTimeout() will get into the callback queue once the timer is done with 1000ms.
But guess what... The callstack is not empty when the timer is done with it's work.. Its still busy performing the 3 seconds CPU intensive task we wrote(Yea.. Its a simulation.. Not a real world dumb program that takes 3 seconds to do whatever its intending to do).
So, the callback functions in the callback queue and the microtask queue would starve.. Poor callback functions. They only get the chance to get into the callstack after 3 seconds.. And that's the reason why we see the "hello world" being printed out after 3 seconds even tho I specified 1000ms.

Yea. This is a random image of the event loop I downloaded from the web.. Cool Image.

Let's take a Go code that does the excat same..

package main

import (
    "fmt"
    "time"
)

func main() {
    time.AfterFunc(1*time.Second, func() {
        fmt.Println("Hello world")
    })

    // Simulating a long CPU-intensive main thread task
    startTime := time.Now()
    for time.Since(startTime) < 3*time.Second {
    }

    print("End")
}

Here, the "hello world" gets printed out after 1 second.. How? Because the AfterFunc() is running on its own GoRoutine which has no business in interfering with the main GoRoutine..

Reason 2: I personally hate client side rendering..

Let's talk about reactJS. It pushes the javascript components to the client and shoves the client's throat with so many things that the clients start to throttle..
Imagine a low end PC making a request for some static HTML file, and you get a bunch load of react component shits.. How would the client feel? It gets slow.. The browser has to parse the javascript, execute the virtual DOM, generate the HTML out of it.. And what not..
The browser is doing all the work that the server has to do..
Remember the NATURAL FLOW OF WEB?
First load the HTML, only then load the javascript? Why? To make the initial paint as fast as possible.. Remember the days when we load the javascript in the footer of the HTML documemt?
React just made the entire flow upside down.
And in result, the client has to stare at a blank white screen for a solid amount of time..

With the reasons being said..

I am choosing 2 languages that shines in their own world..

Go

The thing that straight up impressed me was that Go is a compiled language and is statically typed.. You can blindly say, Go is super fast and is a lot faster than javascript..
It has inbuild light weight threads called "GoRoutines" which is a lot faster than actual OS threads as the Go threads are light weight.
Go can be used to build RESTful endpoints or can be used for any backend service..
BUTT, I cannot use Go for SSR.. PHP shines in that.. In my stack, Go will be heavily used for CPU intensive API's or any backend service.

PHP

PHP is the best thing I ever used for SSR. Simple and very straight forward. Creates a process for each client.. Makes it kind of slow. But still these processes are independent of each other unlike threads that will share the same process memory space and is bad for race conditions and a lot other thread related issues..
PHP is also tightly coupled with the web in my opinion.. The straight out of the box superGlobal variables like $_GET, $_SERVER, etc.. which makes it easier to work with the web in general..
The session management in PHP is just too good.. Comes with the language itself.. And is too easy to manage the sessions..

Conclusion:

PHP can be purely used for SSR. And session management. I can't trust PHP for doing CPU intensive tasks as it sucks in that. Why? Its an interpreted language and its also not multithreaded..
So, I offload all the CPU intensive calls to Go.
Best of two worlds.. PHP for SSR, so that the client wouldn't suffer and Go for CPU intensive tasks because it can do concurrency so well...