DEV Community: Adhithyan B

Through the Tunnel(Ep-5 of The $0 cloud)

Adhithyan B — Tue, 11 Aug 2026 13:40:47 +0000

After searching for a solution (I just GPT'd my way through it lol), I found that Cloudflare was the way to go.

The thing about CGNAT (Carrier-Grade Network Address Translation) is that it allows outgoing requests. Things like opening YouTube, calling an external API, downloading files, or even my server pulling code from GitHub all work just fine.

Cloudefare tunnels

Cloudflare creates a secure tunnel that lets it communicate with my server even though it's sitting behind CGNAT.

The flow is roughly:

Visitor → Cloudflare → Tunnel → My Server

And the response follows the same path back.

But the cool part is, Cloudflare isn't actually punching through CGNAT.

It uses an already-existing connection that my server made to Cloudflare, and routes the incoming requests through that connection.

So I created an account on Cloudflare, tried installing Cloudflare Tunnel, and found out they provide stable Docker images for it.

So obviously, I installed it through Docker because at this point, I'm doing nearly everything with Docker—Postgres, Nginx, and even my database storage!

And I was able to test the tunnel quickly with a temporary tunnel and URL. I opened the URL using my phone's mobile data.

And oh boy... I finally did it.

A website, hosted from my own server, running behind my own network, and accessible to anyone on the internet.

That feeling was awesome.

The problem was, I definitely needed a domain—or maybe I didn't, but buying one seemed like the most feasible option.

Cloudflare's temporary tunnel gave me HTTPS and a random URL, but that URL wasn't something I could properly control or use as a permanent address.So there was no permanent URL that I could actually control.

All that's left now is to buy a domain, configure it, and point it to my server.

The $0 Cloud

And that's it.

I started this whole thing with one simple goal: host a website from my own server without spending a penny.

And somehow, along the way, I ended up learning about Linux, Docker, networking, CGNAT, Nginx, SSH, Cloudflare, and a whole lot of things I never expected to touch.

But hey... I actually did it.

I hosted my own website. From my own server. Without paying for hosting.

Ports and Packets (Ep-4 of The $0 cloud)

Adhithyan B — Thu, 06 Aug 2026 07:03:16 +0000

After all that—setting up Nginx and hiding the ports—I was excited because I thought I was finally going to deploy my website without spending a single penny or relying on free tiers.

But just blindly throwing everything onto the internet felt wrong, so I started learning how packets actually travel from the internet to my machine.

And oh boy, did I learn a lot.

As I dug deeper, I learned that packets don't magically know where my server is. They travel through routers, ISPs, and a bunch of systems in between.

I found out that my router wasn't actually exposed to the internet the way I thought it was. To receive packets from anywhere in the world, I needed a public IP address.

I ran a few scripts on my server, found what I thought was my public IP, and even set up port forwarding in my ISP's admin page. Then, I switched to mobile data and tried accessing it from outside my network.

But there was a problem (no shit, Sherlock).

The website didn't load, and I was completely confused. That's when I noticed that my "public" IP address started with 10.

A quick search later, I discovered that addresses starting with 10.x.x.x are private addresses—they aren't reachable from the public internet.

And that could only mean one thing: it wasn't actually my router's public IP.

CGNAT: The Big Dawg

Most Indian ISPs use something called CGNAT (Carrier-Grade Network Address Translation).

What does it do? Instead of giving every router its own public IP address, the ISP groups multiple routers in an area behind a single public IP. Why, you ask?

Back in the early days of the internet, people thought that a 32-bit address space would be more than enough for everyone. Turns out, they were very, very wrong. IPv4 addresses are running out, and because of that, dedicated public IPs have become expensive.

Anddd the problem is, I can't forward requests to my server anymore because I don't control the public IPv4 address—my ISP does.

There are a few ways around this. I could simply request a public IP from my ISP, but that costs extra money and completely destroys the motto of this series:hosting a website without spending a penny.

Turns out, the internet had one more trick up its sleeve: Cloudflare.

The Middelmen (Ep-3 of The 0$ Cloud)

Adhithyan B — Tue, 28 Jul 2026 13:40:32 +0000

It turns out the internet is full of middlemen. Some forward requests, some establish trust, and some simply make communication possible. I learned about two of those middlemen: Nginx and SSH.

Learning about networking and all that stuff during my college days was always like, "Meh... it's just protocols, IP addresses, and a bunch of theory. Nothing much, man."

But after I started building my own server to host websites, those same boring concepts started hitting me in a way I never expected they would.

So, after learning a bit about Docker and writing my Compose file, GPT suggested that I use Nginx as a reverse proxy. It also explained why exposing my services and their ports directly to the internet isn't considered a good practice, the attack surface is more in that way.

nginx and proxying

Nginx turned out to be far better than I expected. It acts as a reverse proxy, sitting between the browser and my services. Instead of exposing my services directly, the browser communicates with Nginx, and Nginx forwards the requests to the appropriate service behind the scenes. thats cool right!

So I wrote my first Nginx configuration, and voilà—I had all my services running behind Nginx, hidden from the browser.

I thought that was all Nginx did. Nope... and that honestly blew my mind.

With Nginx in front of all my services, I only expose one public entry point. This keeps things simple and easier to scale. It also makes HTTPS and custom domains much easier to handle—I’ll cover that in a later post.

I also discovered that Nginx can do things like load balancing and caching. I haven't needed those yet, but it's nice knowing the same tool can grow with my projects.

SSH – The Other Middleman

As I mentioned in my previous episode, let's talk about SSH authentication.

I also connected my Windows machine to the server over SSH because, honestly, working on two separate laptops was a hassle.

Being able to SSH into the server directly from my Windows machine meant I could do everything from one place without constantly switching devices, and it made the whole workflow so much better.

Anddd I did the same with GitHub. So basically, we need to create an SSH key pair on the server and give the public key to GitHub. From then on, GitHub knows that the server is actually someone it can trust.

How, you ask?

It sends a challenge that can only be solved using the server's private key. The server signs the challenge with its private key, GitHub verifies it using the public key it already has, and if everything matches, it knows the server is trustworthy.

Yeah... I don't think I explained that very well, but that's basically the idea lol.

Now all that's left for me is to buy a domain, hook everything up, and finally deploy my website... right??

The Real Benefits of Docker(Ep-2 of The $0 Cloud)

Adhithyan B — Sun, 26 Jul 2026 12:33:30 +0000

I didn't quite understand Docker the way I wanted to.

For me, Docker was just this basic container-type thing where the configuration of my project is frozen so that it runs the same way on every device. Which is partly correct, but there's a much bigger picture and a lot more use cases than I initially realized.

More Than Just Images and Containers

One of the biggest advantages I noticed was how naturally everything became separated. Instead of treating my project as one giant application, I suddenly had a frontend image, a backend image, and a database image. Updating one service no longer meant rebuilding everything else.

Docker also taught me how to be more efficient when building applications. It introduced me to the concept of standalone builds, which significantly reduce image size while making builds faster and deployments more efficient.

docker-compose.yml

Along the way, I learned about containers, images, and volumes—how a single image can be used to create multiple containers, why database data should always live in volumes so it isn't lost when containers are recreated, and a whole lot more.

I also ended up writing a Docker Compose file for my project because, let's be honest, nobody wants to start every service one by one every single time. And oh boy, the amount of customization and configuration Docker Compose offers is unreal.

The fact that you can copy only the files you actually need into an image, define entire application stacks in a single file, and have Docker provide its own built-in DNS service so containers can talk to each other by name without worrying about IP addresses or routing... that's just insane. It genuinely made me appreciate how much work Docker hides behind such a simple interface.

After creating the Compose file and tweaking it until everything worked, I finally got all the services running on my localhost. Seeing the frontend, backend, and database come up together with a single command was incredibly satisfying.

moving file to the server

Now, all that was left was to move the codebase to the server along with the Compose file and see if everything worked outside my local machine.

Aaaand... I did exactly that.

I copied the project over, set up an SSH connection so GitHub and my server could trust each other (I'll cover that in a future episode because it's a pretty neat topic on its own), and got everything ready for the real test, and it worked !!!

problem with exposing ports

There was just one problem left.

At this point, the application was only accessible on localhost. On my Windows machine, only my Windows machine could access it. On the server, only the server itself could access it.

Sure, I could expose it using the server's IP address and access it from another device, but exposing your application directly over an IP isn't exactly a great idea. It works for testing, but it's definitely not how you'd want to host something that other people can access.

And i stumbeld upon a thing called nginx and apparently, the stack wasn't quite complete yet..

Getting started (EP-1 of The $0 Cloud)

Adhithyan B — Fri, 24 Jul 2026 06:07:55 +0000

The idea of having my own server never really interested me until I had a conversation with one of my developer friends.

We were discussing how students can deploy their projects—mainly software applications—to the internet without burning through their wallets on cloud services. For someone just starting out, cloud hosting costs can add up surprisingly fast. That's when he suggested something I hadn't seriously considered before: building your own server and deploying your applications from it.

Will it support enterprise-scale traffic? Nope.

But for my own projects, portfolios, MVPs, or small applications? It seemed more than capable. And for someone who's just getting started building products, that sounded like a pretty good deal.

The set-up

So, I decided to set up my own home server. Luckily, I had an old laptop lying around that no one in my house was using anymore. I grabbed a USB drive, and my next task was figuring out which Linux distro (OS) would be the best fit for a server.

I had a chat with GPT, and it recommended Ubuntu Server LTS. It's a great beginner-friendly server distro, comes without a GUI, and has excellent community support—perfect for someone just getting started.

Once I settled on Ubuntu Server, I created a bootable USB, wiped Windows completely off the old laptop, and installed Ubuntu Server. After a few minutes of setting up the server name, user account, password, and the usual configuration, I officially had my very first server up and running.

And it was honestly super exciting to set everything up. Using a server without a GUI made me feel like I was in some B-grade hacker movie, just typing commands into a terminal. It was also surprisingly fun installing packages and slowly building up the server the way I wanted.

The dilemma

Turns out my friend had a reason for setting up a home server. He was tired of not having a proper way to host watch parties with friends, so he was building his own personal Netflix-like server with watch party features.

And me? I was just hyped by the whole idea and started building one. Here I was, after setting everything up, with absolutely no clue what I actually needed a home server for.

Then I remembered the conversation I'd had with my friend a long time ago about self-hosting applications. Since I already had a Linux server sitting there, I decided to host my own website on it and see where things went. I also wanted to set up my own media server because, honestly, the idea just sounded super cool.

I thought a home server was something you'd build for one specific purpose. Then I discovered Docker, containers... and an entirely new rabbit hole.

Going Towards Nothing (But Still Applying Anyway)

Adhithyan B — Sun, 29 Mar 2026 04:54:19 +0000

Applying off-campus, especially in this job market, has been a greater battle for the past couple of years. As AI ATS and other “AI methods” have entered application filtering, it is even harder for employers to notice good employees with good skill sets. HR who put random skill sets they hear from their technical colleagues lead to job descriptions like “we need db, machine learning, UI/UX designing, in a nutshell, everything,” and all for a 12-hour unpaid intern.

Desperation and Its Impact on Mental Health

The “12-hour unpaid intern where you do literally everything” sounds cruel from a sane point of view, but students and freshers still apply to them, thanks to desperation.

Peer pressure, placement panic, news about layoffs, and a tough job market for freshers all cause individuals to doubt their potential. This can lead to a spiral of low self-esteem and self-doubt about their abilities, preventing them from thinking clearly and leading to anxiety attacks and breakdown episodes.

The thought of "I know this internship is terrible" yet still applying for it can really disturb your peace of mind. It feels like you're heading towards failure, making you more vulnerable and desperate.

The Art of Writing Unrealistic JDs

HRs… I don’t know what they’re doing half the time. And most startups and mid-size companies that don’t have a proper hiring workflow just let HR handle the JDs. And oh boy, the descriptions are wild — “Node, API, REST API, React, Vue.js, Angular” — all for an entry-level or intern role for UI/UX designing. BRUH.

And this leads students and freshers to juggle skill sets half their life, trying to tick every box, and in the process they don’t specialize in a single skill — basically ending up learning none properly at the end of the day.

HRs should actually sit down and have a proper talk with their tech colleagues and ask them “even if the market is sad right now what skills a fresher really needs to have”, and then write the JD based on that.

The market is bad, sure. But that doesn’t mean students should turn into “do everything” machines just to survive it.

Unrealistic expectations from companies shouldn’t become unrealistic pressure on ourselves.

From Excitement to Silence: What Building My First Open Source Project Taught Me

Adhithyan B — Sun, 02 Nov 2025 09:46:51 +0000

I am always fascinated by how open source grows into a full community from small PR requests, issue raises, eventually becoming something big.The number of people/developers who benefit from open source initiatives is significant.

What makes open source truly beautiful is the community it has, with a vast variety of minds and different approaches to solving issues. We can gain valuable insights and programming practices from these contributors.

So, being the curious cat I am, I wanted that feeling—the feeling of building a community and learning as I go. I started brainstorming on what to solve, whether I should start big or small, and what tech stack to use. Basically, I was daydreaming about the moments where I'd be maintaining tons of PRs and issues.

Then came a perfect idea—whenever I’m designing screens and mockups in Figma, I end up with a dozen tabs of design tools open and no clue which one’s which. Total chaos. So I figured, why not build a curated tools platform where designers and frontend developers can browse resources and tools by category—UI/UX, React, and so on. It felt like the perfect idea: it solved a real-world problem (for me, at least) and was the ideal gateway to learn about open source. Also, my resume was looking a little dry, so this felt like the perfect time to add value to it.

What Came After the Build

Finished the project and I was genuinely proud of myself.Went to GitHub, set up branch rules, wrote docs for everything, even raised a few issues myself so contributors would have something to work on.

Then came the waiting game. “Now we wait,” I told myself. And the result? Not a single soul clicked my links. Got a few pity views when I posted it on LinkedIn and shared it with friends, but after four to six months… I couldn’t honestly say my website helped anyone. No tool submissions, no PRs, no issues — just the three I raised myself. (And yeah, I solved one of them).

But here's the thing — it was still rewarding.
Sure, the website isn't perfect since I vibe coded half the backend stuff (the code structure and API routes are… let's say, questionable), but I learned things I once swore I'd never touch.

I got my hands dirty with backend stuff — APIs, HTTP, all that black magic.
I dove into SQL, learned how to create tables and manage them through an ORM.
And on top of that, I finally got a grip on responsive design. I got myself a decent project to put on my resume and portfolio.

Start Early

You don't need to know everything to start something new.

This has always been true, even before AI, Developers would build with what they knew and then search Stack Overflow and documentation to learn what they didn't know and explore further. Now, it's even faster with AI—if you have a new question, just ask it. And if you prefer the old way, you can ask AI to scrap the specific documentation and sections you need.

The key is to just start. You never really understand what you’re dealing with until you dive headfirst into the rabbit hole — failing, getting frustrated at your own code, and trial-and-erroring the most ridiculous things.

But that’s the point doing it anyway.

We novice developers often fall into the perfectionist trap!

Trying to get everything right on the first attempt.Ironically, that tendency fades only with experience… and to gain experience, you’ve got to actually do the thing.

A 2014 study by Denny, Luxton-Reilly, and Simon backs this up. They explored the “build–measure–learn” loop and found that when learners get immediate feedback and are encouraged to “try–fail–fix,” their performance improves significantly — proving that doing first and perfecting later beats the “perfect-first” mindset every time.

The perfectionist mindset also comes with baggage.It leads to more stress, lower learning outcomes, and a tendency to procrastinate — because when you’re obsessed with getting it just right, you end up doing nothing at all.

Final thoughts

If you’re planning to build something — big or small, simple or complex — just start.

Do it, and learn as you go. Especially now, when AI has come such a long way, don’t hate it — use it smartly. Let it accelerate your learning, not replace it.

Make it exist first. Don’t know backend? Vibe-code it. Ask what each function does along the way. Once it’s done, go back, read the docs, and learn the deeper stuff.

Did the project bring in skyrocketing traffic? Probably not.
Did you step out of my comfort zone and learn some cool shit? Definitely!

Because at the end of the day, progress beats perfection every single time.

If you’re curious (or just want to see the ancient ruins of my open-source experiment): https://dev-juice.vercel.app/

How I see AI as a Fresher Frontend Dev

Adhithyan B — Thu, 30 Oct 2025 02:12:06 +0000

The moment I started learning HTML, CSS, and other frontend frameworks, I had one rule for myself: “Minimal to no AI usage — I want to learn things deeply and build a solid foundation.” It sounded like a foolproof plan. And to be fair, it was on paper. But in practice? I was learning properly, just not effectively. Endless tutorial hells, half-finished projects scattered across folders, and the occasional mini breakdown made me wonder if this was just part of the developer's ritual or if I was doing something wrong.

AI isn't a threat that replaces beginners—it's actually a valuable learning tool.

I realized this during my internship at a GenAI startup, where we were building a chatbot-like solution.I was in charge of designing and developing the frontend. Everything was fine until it came time to turn the mockups into a React app. Problem was, I was new to React and struggling to keep up with deadlines. So i took a React course and followed it through. I did learned the core concepts, got familiar with components, hooks and props (basic react essentials), and finally started piecing things together.

After learning the basics, I started building the frontend for the project. So, was I suddenly delivering sleek, production-ready components? SIKE I was even slower than before second-guessing every decision.
“Is this how they do it?”
“Is this production-ready?”
“Am I overcomplicating things?”

Eventually, I dropped my ego and thought, “Welp, let me try GPT.”
And honestly, it helped A LOT. I started learning new concepts and breaking down tough ideas into something I could actually understand. It even showed me real-world examples of how professional devs approached similar problems, which helped kill that constant self-doubt.

In short, I started learning in my own way instead of blindly following tutorials or documentation. Those are great once you know the fundamentals — but early on, you need something that speaks your language, not just the “YouTuber” way of doing things.

AI still struggles with frontend and creative aspects!

When it comes to frontend, AI still has a long way to go. Sure, it can spin up a landing page with fancy animations and filler content in minutes(which is impressive not gonna lie). But after scrolling for a few seconds, you can instantly tell “Nope tis shit AI“.

That’s because AI still can’t replicate creative juices, the thought process behind every margin, motion, or hover effect. A developer-built site feels alive because there’s reasoning behind each and every design choice. When a dev explains why a certain animation triggers or how a layout guides user focus, that’s creativity, not computation.

When I was building a bento layout for one of my projects, I wanted it to be responsive across all viewports. The problem was I barely knew how TailwindCSS handled responsiveness at that point. So, I asked GPT to make the layout responsive and gave it some context about how many rows and columns each viewport should have.

It did give me code, but it also completely wrecked my existing structure. The layout I had carefully built turned into something unrecognizable. Still, it wasn’t a total waste I got a basic idea of how responsiveness worked. After a few tweaks and some trial and error, I finally achieved the desired outcome.

Ironically, it probably would’ve taken me less time if I’d done it all from scratch.

AI might eventually get better at mimicking creativity, but for now, it’s still has alot to catch up. In my opinion, design, the art of making something feel right and overall creativity might be the toughest skill for AI to truly recreate.

Final Thoughts

If you want AI to give you great results, you have to feed it context — what you want, what you expect, and what it should avoid. But to provide context you first need to understand the basics of what you’re asking for.

If you want a different layout for mobile and desktop, you should already know how grids and flex work. If you’re going for parallax scroll animations, you need to understand concepts like delay and stagger.

AI can help you move faster and explore new ideas, but it can’t replace a developer’s understanding or creative intent. At the end of the day, it’s just a tool. Ignoring it isn’t an option either it’s already part of the workflow in most modern organizations.