DEV Community: Jay Bhavsar

How to Make the Most of a Cheap IPv6-Only VPS: A Guide for Self-Hosting Enthusiasts

Jay Bhavsar — Tue, 22 Apr 2025 12:42:26 +0000

Found a dirt-cheap IPv6-only VPS—maybe from v6Node, Vultr, or one of those $2/month deals? Wondering what to do with it?

If you're into self-hosting, the answer is: a lot.

Why Go IPv6-Only?

IPv4 is scarce and expensive. IPv6 gives you a practically unlimited address space. That’s why many providers offer IPv6-only VPS at a huge discount.

The catch? Not everything on the internet supports IPv6. But if you’re okay with a few workarounds, it’s a steal.

What Can You Use It For?

1. VPN Server

My #1 reason for getting one.

Set up WireGuard or OpenVPN. If that sounds like too much work, try Twingate or Tailscale:

Twingate: route only selected traffic through your VPS.
Tailscale: configure it as an exit node to tunnel all traffic.

Perfect for bypassing local restrictions and improving privacy.

2. Dockerized Services

Run your favorite self-hosted apps. I use mine for:

qbittorrent
jellyfin
nextcloud (the built-in office suite is underrated)
linkwarden (bookmark manager)
bitwarden (password manager)

3. Personal Web Hosting

Great for blogs, portfolios, or static sites. Simple and effective.

4. Remote Dev Environment

I run Coder on mine — lets me use a full dev environment in the cloud. I can connect using VS Code (either in the browser or locally), and even use JetBrains IDEs like IntelliJ with remote support.

Feels native, runs heavy tasks on the VPS, and keeps my laptop cool.

5. Learning & Experimentation

Mess around with:

New Linux distros
Infrastructure as Code (Terraform, Ansible)
Docker + Kubernetes basics
Self-hosting monitoring stacks (Prometheus + Grafana)
CI/CD experiments (GitLab Runner, Drone CI)
Reverse proxies and networking (Traefik, Nginx, Caddy)
Fail2ban, UFW, and SSH hardening
Automating cloud backups
Running your own email server (if you’re brave)
Benchmarking tools and performance tuning

Cheap, isolated, and disposable. Ideal lab setup.

Handling IPv4-Only Clients

If you need to expose your IPv6-only services to the IPv4 world, use a reverse proxy like Cloudflare Tunnel. It lets you serve your content to both IPv4 and IPv6 clients—without needing a public IPv4 address.

Happy self-hosting!

Inversion of Control (IoC): Demystifying the Familiar Pattern

Jay Bhavsar — Thu, 04 Apr 2024 10:51:14 +0000

Senior devs, if you are working on fairly complex real life project, you already know and use lots of IoC principles. Here's a quick refresher with examples, without much jargon.

Inversion of Control (IoC) is a design principle where control over program flow is shifted to an external framework or container, promoting flexibility and modularity. Note that it is only a principle (or philosophy). Here are some common implementations we see in real world engineering.

Dependecy Injection (DI)

Ever used or defined a parameterized constructor? That's DI in nutshell.
Instead of letting constructor figure out things on its own, you, the caller, pass parameters. Parameters in this case are dependencies, and you as a caller is injecting them. Here's an intuitive example:

class Calculator {
    private int precision;
    Calculator() { // bad example, since no DI here
        this.precision = 2;
    }
    Calculator(int precision) { // good example, since caller can pass precision
        this.precision = precision;
    }

Same reasoning can be applied to any method with parameters.
Ever used @Autowired in Spring? That's also DI. (more details in next section)

Relating to IoC principle: With DI, control is inverted from method to caller. That's IoC.

Inversion of Control Containers

IoC Containers make it easier to do DI in enterprise applications. It takes care of DI and lifecycle management (@PostConstruct and @PreDestroy annotations). Below are 2 code snippets, showing how code looks with and without IoC.

@Repository
class UserRepository { 
    public void save(User user) {
        database System.out.println("User saved: " + user.getName()); 
    } 
}
@Service
class UserService {
    @Autowired private UserRepository repo;
    public void saveUser(User user) {
        this.repo.save(user);
    }
}
public class MainApp {
    @Autowired UserService userService;
    userService.saveUser(new User());
}

class UserRepository { 
    public void save(User user) {
        database System.out.println("User saved: " + user.getName()); 
    } 
}
class UserService {
    private UserRepository repo;
    public UserService(UserRepository repo) {
        this.repo = repo;
    }
    public void saveUser(User user) {
        this.repo.save(user);
    }
}
public class MainApp {
    UserRepository repo = new UserRepository();
    UserService userService = new UserService(repo);
    userService.saveUser(new User());
}

Notice how first code is less verbose since Spring takes care of DI. Now, you might imagine how complex and messy this can get for more complex use cases.

Relating to IoC principle: Control of DI in inverted from programmer to framework.

Template Pattern

Ever used inheritance? That's template pattern.
In this pattern, the control flow of an algorithm is defined in a base class, while specific steps of the algorithm can be implemented in subclasses.

abstract class Beverage {
    public final void prepareBeverage() {
        boilWater();
        brew();
        pourInCup();
    }

    abstract void brew();
    abstract void addCondiments();

    // Common methods with default implementation, can be overridden by subclasses
    void boilWater() { System.out.println("Boiling water"); }
    void pourInCup() { System.out.println("Pouring into cup"); }
}

class Coffee extends Beverage {
    @Override
    void brew() { System.out.println("Dripping Coffee through filter");}
    @Override
    void addCondiments() { System.out.println("Adding sugar and milk");}
    @Override
    void pourInCup() {System.out.println("pouring into takeaway cup"); }
}

class Tea extends Beverage {
    @Override
    void brew() { System.out.println("Steeping the tea"); }
    @Override
    void addCondiments() { System.out.println("Adding lemon"); }
    void sip() { System.out.println("Sipping tea!"); }
}

public class BeverageMaker {

    public static void main(String[] args) {
        Beverage coffee = new Coffee();
        System.out.println("Making coffee...");
        coffee.prepareBeverage();

        System.out.println();

        Beverage tea = new Tea();
        System.out.println("Making tea...");
        tea.prepareBeverage();
    }
}

Relating to IoC principle: Instead of relying on subclasses for implementation, control is given to abstract class to have set methods. This also allows customizations (see Coffee.pourInCup() and extensions (see Tea.sip()).

Factory Pattern

Factories are used to create instances of classes or components. They encapsulate the logic for creating objects, allowing for flexible instantiation based on runtime conditions. Consider following example for better understanding:

interface IStorage { void store(File file); }
class AwsStorage implements IStorage { 
    @Override public void store(File file) {
        System.out.println("Storing " + file.getName() + " in AWS"); 
    } 
}
class LocalStorage implements IStorage { 
    @Override public void store(File file) {
        System.out.println("Storing " + file.getName() + " in Local FS"); 
    } 
}
class FTPStorage implements IStorage { 
    @Override public void store(File file) {
        System.out.println("Storing " + file.getName() + " in FTP"); 
    } 
}

class StorageFactory {
    public static IStorage getStorage(String storageType) {
        if ("AWS".equalsIgnoreCase(storageType)) {
            return new AwsStorage();
        } else if ("LOCAL".equalsIgnoreCase(storageType)) {
            return new LocalStorage();
        } else if ("FTP".equalsIgnoreCase(storageType)) {
            return new FTPStorage();
        }
        return null;
    }
}

public class Main {
    public static void main(String[] args) {
        StorageFactory.getStorage("AWS").store(new File("file.txt"));
        StorageFactory.getStorage("LOCAL").store(new File("file.txt"));
        StorageFactory.getStorage("FTP").store(new File("file.txt"));
    }
}

Notice how client (Main class) can call getStorage() and store() without knowing much about their implementations. getStorage() is also extensible without modifying the client code. This also makes it easier to slice and dice our code to inject mock implementations for testing.

Relating to IoC principle: The control of object creation in inverted from client and delegated to factory component.

Event Handling

This is very common pattern seen across many programming languages. Let's start with and example:
There's a door, and when it opens we want to alert security.

class Door {
    private String name;
    public Door(String name) {
        this.name = name;
    }

    public void open() {
        System.out.println("Door " + name + " is opening.");
        System.out.println("Security system notified: Door " + name + " opened.");
    }
}

public class Main {
    public static void main(String[] args) {
        Door frontDoor = new Door("Front Door");
        frontDoor.open();
    }
}

This works okay, but there's a major problem with it as it grows more complex. Let's say client only wants to alert security based on some condition. Or let's say we want to turn on lights when door is opened. Door class is tightly coupled with security and violates SRP (Single Responsibility Principle). Here's how we can fix it:

class DoorEvent {
    private Door door;
    public DoorEvent(Door door) {
        this.door = door;
    }
    public String getDoor() {
        return door;
    }
}
interface DoorListener {
    void doorOpened(DoorEvent event);
}
class Door {
    private String name;
    private List<DoorListener> listeners;

    public Door(String name) {
        this.name = name;
        this.listeners = new ArrayList<>();
    }

    public void addDoorListener(DoorListener listener) {
        listeners.add(listener);
    }

    public void removeDoorListener(DoorListener listener) {
        listeners.remove(listener);
    }

    public void open() {
        System.out.println("Door " + name + " is opening.");
        // Notify all listeners that the door is opening
        for (DoorListener listener : listeners) {
            listener.doorOpened(new DoorEvent(door));
        }
    }
}

// all the external systems
class SecuritySystem implements DoorListener {
    @Override
    public void doorOpened(DoorEvent event) {
        System.out.println("Security system notified: Door " + event.getDoorName() + " opened.");
    }
}
class LightingSystem implements DoorListener {
    @Override
    public void doorOpened(DoorEvent event) {
        System.out.println("Lights turned on: Door " + event.getDoorName() + " opened.");
    }
}
//client
public class Main {
    public static void main(String[] args) {
        Door frontDoor = new Door("Front Door");

        SecuritySystem securitySystem = new SecuritySystem();
        LightingSystem lightingSystem = new LightingSystem();

        frontDoor.addDoorListener(securitySystem);
        frontDoor.addDoorListener(lightingSystem);

        frontDoor.open();
    }
}

This is better because control is with the caller. Caller don't need to know about interfaces or events at all. This code is also extensible, meaning we can add more implementations of `DoorListenerwithout modifyingMainorDoor` class.

Relating to IoC principle: Here Door class don't have control over handling DoorEvents. This control is now delegated DoorListener (external component).

Aspect-Oriented Programming (AOP)

AOP aims to separates cross-cutting concerns, such as logging, security, or transaction management, from the core business logic. It can be applied to multiple classes or components without modifying their code directly.

Imagine you are tasked to add log line before and after every function call in some class UserRepository. Here's how you can do it with AOP.

`java
@Aspect
@Component
public class UserRepositoryLoggingAspect {
@Pointcut("execution(* package.repository.UserRepository.*(..))")
private void userRepositoryMethods() {}

@Before("userRepositoryMethods()")
public void logBeforeMethodExecution() {
    System.out.println("Logging before method execution...");
}

@After("userRepositoryMethods()")
public void logAfterMethodExecution() {
    System.out.println("Logging after method execution...");
}

}
`

Notice, how this is accomplished without even looking at code in package.repository.UserRepository.

Relating to IoC principle: Here the control in inverted from UserRepository to UserRepositoryLoggingAspect. The UserRepository class does not directly handle or specify the logging behavior; instead, it is automatically intercepted and augmented with logging functionality by the Spring framework.

Hope this helps, let me know what you think in comments! Checkout my website for more: https://jay.is-savvy.dev/

OAuth Terms Explained in One Sentence

Jay Bhavsar — Fri, 09 Feb 2024 16:31:42 +0000

I made this note for a quick reference to my future self.
OAuth 2 aimed to replace traditional session based auth, because of security and management issues.
OAuth was originally designed to handle only authorization and not authentication.

Terminology

Resource Owner

User who own the data, the one who is trying to log in. You.

Client

The app requesting your data. eg. Calendly

Authorization Server

Server that verifies user's identity. eg. accounts.google.com

Resource Server

Server that hosts resources needed by client. eg. api.calendar.google.com

Authorization Grant

Permission from authorization server. aka auth code

Redirect URI

Where to pass authorization grant. (usually back to client's servers) eg. api.client.com/callback

Access Token

Token for accessing resources from Resource Server

Response Type

It can be either token or code. Code is more secure involving back channel. Passing response type=token would give you access token directly without authorization grant (auth code).

Scopes

Specific granular permissions. list of scopes that authorization server understands. Client sends list of scopes to request data. eg. Permission to read your age, email, name etc.

Consent

Consent screen popping up when signing in. eg. Consent screen when logging in with Google

Back Channel - highly secured channel

Backend server of client, eg. python code running in Calendly's servers

Front channel - less secured channel

Browser, eg. Javascript Calendly app running on user's browser

Flows

Flow, in laymen terms, means "the login/signup flow" -- process of app requesting access, user providing consent, token generated and passed back to client. There are 4 flows supported:

Authorization code (front channel + back channel)
Implicit (front channel only)
Resource owner password credentials (back channel only)
Client credentials (back channel only) ## Problems with OAuth 2.0 for Authentication
No standard way to get users information
Every implementation is a little different
No common set of scopes ## OpenID Connect Introduced to solve the authentication problem. It is a small layer on top of OAuth. ### OpenID scope the only new thing added. this mean the flow is now OpenID connect flow. ### ID token similar to access token, but used to identify user instead of authorizing them within some scopes. it is JWT token.

Claims

JWT token has 3 sections. header, signature and body. body is also known as claims or payload. claims is decode by the application and can be used to retrive user data.

/userinfo

this endpoint is implement by the auth server as a standard. the client can hit it to get basic info like name, email and profile pic.

Reference

This is an excellent presentation by Nate Barbettini, who clearly explains OAuth2 in simple terms. Highly recommenced watch.

Scaling Cheer: A Deep Dive into the Architecture of Red Jingles AI Chatbot

Jay Bhavsar — Fri, 15 Dec 2023 12:28:58 +0000

A state-of-the-art holiday theme-based AI chatbot focusing on scalability, extensibility and real world applicability.

Official submission to Serverless Holiday Hackathon 2023 hosted by Serverless Guru

Checkout the hosted app, Santa and the team waiting for you here!!

Also check out GitHub Repo

Submission by:

Jay Bhavsar and Riya Bhavsar

1. Purpose and Objectives

The world has witnessed AI's potential thanks to platforms like OpenAI. It's crucial that AI isn't just limited to tech experts but accessible to everyone.

Red Jingles is our attempt to create a chatbot backed by LLM with a Christmas theme featuring Santa Claus, Snowman, and Elf.

Beyond the initial fun, this interaction is more than just choosing a character. Users feel engaged, empowered, and heard when their preferences are considered instantly. This transforms the interaction from machine to virtual character, making it feel like talking to a friend.

Red Jingles offers a unique, joyful AI conversation experience that doesn't feel like traditional AI. It makes interactions more personal, engaging, and fun, creating a deeper connection.

2. Functionalities and features

Authentication: Users sign up using their email, which undergoes verification. Subsequently, they can log in using their verified email and password for application access. We have a strong password policy in place to have a minimum 8 chars and mix of uppercase, lowercase, symbols and numerics.
Selecting Christmas themed characters: Users enjoy a unique and fun aspect by selecting one of three Christmas characters — Santa Claus, Snowman or Elf. Each character has a unique personality and charm.
Have a conversation with AI, ask anything: Centered around the holiday theme, common inquiries may revolve around gift suggestions, recipes, dinner plans, home decor, travel tips, and more, though there is no limitation for any genre. AI can access the internet to get up to date and accurate information.
Contextual memory: Temporary memory assists the AI in quicker responses and better understanding during extended and deeper conversations.
Persistent storage: Users benefit from permanent storage, enabling them to refer back to previous conversations with the AI for valuable insights at any time. Users can also resume any previous conversation.
API for developers: We have exposed REST APIs as a separate service. It is also secured with the same auth mechanism as the chat app. It follows OpenAPI standard, and has a well documented interactive UI.

3. High Level Design

3.1 Architecture Diagram

NOTE: Chainlit Cloud has since been migrated to literal

3.2 Technical Components in Detail

3.2.1 AWS Cognito

Constructing a robust authentication system is a huge and challenging task. Recognizing that, we opted for a fully managed and serverless authentication service—Amazon’s AWS Cognito.

Configuration:

Authentication with OAuth2 protocol
Email as primary attribute
Required email verification for successful signup
Strong password policy to have minimum 7 characters including lowercase, uppercase, numeric and special characters

3.2.2 Google App Engine

We have deployed 2 GAE services.

Chainlit+Langchain application is containerized and runs on custom runtime and flexible environment.
The other service runs on standard environment and python runtime which hosts LangServe API and documentation

3.2.3 Memorystore (Redis)

Memorystore offers a fully managed serverless redis database. Since redis is a fast, in-memory database, we use it to store conversation context for active chats.

3.2.4 Chainlit Cloud

Chainlit cloud is a fully managed service to store users' chat history. Behind the scenes it uses SQL databases.

3.2.5 OpenAI

OpenAI hosts various LLMs and offers a robust API for their models. We use these LLMs to power our app.

3.3 Scalability

Amazon Cognito

By default, Cognito accommodates up to 40 million users. Specifically, it enables 120 Requests per Second (RPS) for user sign-ins and 50 RPS for user sign-ups (Source: Quotas in Amazon Cognito - Amazon Cognito).

Google App Engine (GAE)

GAE is capable of automatically scaling up to an impressive 2,147,483,647 instances. Its most potent instance type, F4_1G, boasts 3072 MB of memory and a CPU clocked at 2.4 GHz. This scalability equates to serving millions of active users in real-world scenarios.

Google Memorystore

Offering a default quota of 1 terabyte (TB) of storage per region, Memorystore for Redis becomes instrumental. Assuming an average conversation occupies 1 megabyte (MB), this allocation allows support for up to 1 million active conversations per region (Source: Quotas and limits | Memorystore for Redis | Google Cloud).

OpenAI API

With its default quota, the OpenAI API facilitates up to 10,000 Requests per Minute (RPM) (Source: Rate limits - OpenAI API).

Chainlit Cloud

Despite the absence of explicitly mentioned quotas and limits on their website, Chainlit Cloud presents a managed enterprise solution. Accurate estimations can be derived by referencing a self-hosting guide.

3.4 CI/CD Diagram

3.5 CI/CD components in detail

Git

Git serves as a robust version control system, enabling effective codebase management. The code is open source and hosted on the widely used platform GitHub.

GitHub Actions

This feature automates the processes of building and deploying code. When code is pushed, GitHub Actions triggers a sequence of actions. Firstly, it builds the Docker image and subsequently pushes it to Docker Hub. Following the successful completion of the initial action, a second action is triggered. This action executes the "terraform apply" command, implementing any alterations made to the infrastructure.

Docker Hub

The chatbot application is containerized and publicly hosted on Docker Hub, a repository for Docker container images.

Terraform

Terraform operates as an infrastructure-as-code tool, facilitating seamless integration across various platforms, including AWS Cognito, Google App Engine, and Google Memorystore Redis, among others. Google Cloud Storage buckets are utilized to store Terraform state files, ensuring efficient management and tracking of infrastructure changes.

3.6 Design choices summary

Ideation thoughts for choosing a particular service:

AWS Cognito

Chosen over alternatives like Auth0, Okta, and Firebase due to its customizable hosted UI, which provided a straightforward and seamless configuration process.

Google App Engine (GAE)

Selected because of its minimal configuration requirements and excellent scalability. While other serverless solutions like ECS and Cloud Run could be viable, GAE's simplicity and scalability were determining factors.

LangChain

Its open-source nature, large active community, well-maintained documentation, and comprehensive range of tools available out of the box made it extremely user-friendly, especially for newcomers.

Chainlit

Stood out for providing a ready-to-use solution along with infrastructure support, making it a convenient choice for the project's needs.

Google Memorystore Redis

Chosen for its seamless compatibility with applications running on Google Cloud, full management, and serverless functionality. Although alternatives like Redis Cloud and ElastiCache were considered, its integration with GAE was a decisive factor.

OpenAI

Previous positive experience with their APIs led to its selection. While alternatives like AWS Bedrock and Huggingface were viable, the ease of interchangeability in the project's design made it a suitable choice.

Docker

Its ability to establish loose coupling and isolation between application and infrastructure requirements, along with its containerization capabilities facilitating running applications on any host, made it a preferred choice.

Terraform

Highly efficient in supporting Infrastructure as Code (IAC), enabling streamlined infrastructure management and deployment processes.

Acknowledging the evolving nature of technology, we as a team remain always open to future learnings and potential adaptations to emerging tools and services.

3.7 Design Challenges

3.7.1 Abrupt Disconnection of Service

Scenario: During chat interactions, users encountered an abrupt "Service not available" error after initiating conversation, disrupting the flow of dialogue.
Analysis: The application deployed on Google App Engine's flexible environment utilizes VM instances equipped with a front-end load balancer responsible for load distribution. When a user initiates a chat, the request is directed to a specific instance (I1). Subsequent queries might be routed to a different instance (I2), leading to a loss of the previously established webhooks session.
Fix: Set session affinity to true to ensure the load balancer consistently directs requests from the same session to the same origin server.

3.7.2 Configuring AWS Cognito for Chainlit Authentication

Scenario: Chainlit’s limited support for OAuth platforms lacked compatibility with AWS Cognito, creating authentication challenges.
Fix: We duplicated and customized files sourced from the Chainlit library. Subsequently, modifications were made to the library during the Docker image building process. Our intention is to initiate a Pull Request (PR) on the Chainlit repository to introduce support for AWS Cognito. This implementation serves as a valuable resource for individuals aiming to integrate AWS Cognito with Chainlit, offering a clear reference point for such integration.

NOTE: AWS Cognito is now officially supported in Chainlit, and this workaround is not needed anymore

4. Low Level Design

4.1 Directory Structure

There are two primary directories within the project: 'app' and 'terraform.'

The 'app' directory houses all the necessary code and configurations required to execute the application. Meanwhile, the 'infra' directory contains Terraform code, enabling the creation of infrastructure components on the cloud platform.

4.2 Python files

Constants.py: This file serves as a central repository defining the AI characters—Santa, Snowman, and Elf. It includes their names, display names, image thumbnails, system prompts, welcome messages, and other associated attributes essential for their representation within the application.
Agent.py: Responsible for defining and configuring the Langchain agent. It specifically initializes the LLM (Language Model) and allows for customization of the LLM model if needed. Additionally, it provides the capability to configure and incorporate additional tools into the agent.
app.py: Functions as the primary entry point for the Chainlit application. It relies on 'constants.py' and 'agent.py' as its core dependencies. Within this file, all the necessary callbacks for managing conversation handling are defined and implemented.
api_server.py: Serves as the main entry point for Langserve. This file is built using FastAPI and exposes a REST API specifically designed for the agent, facilitating communication and interaction with the AI functionalities provided by the system.

4.3 Code Quality

All the python code follows the PEP-8 styling guide.
Terraform code follows the HCL style conventions.

5. Extensions and Real World Applicability

Enable Multi-Modal Support: Enhance the capabilities of the system to incorporate a wider range of inputs and outputs, expanding beyond text-only interactions. This enhancement aims to enable the AI agent to process and generate responses using various modalities, such as images and documents, in addition to textual inputs and outputs.
Expand Agent Functionality with Additional Tools: Extend the functionality of the AI agent by integrating supplementary tools, including but not limited to email, Slack, Jira, etc. This enhancement aims to configure the agent to access and utilize various personal and productivity tools, allowing for more comprehensive and versatile interactions and task execution within the system.

6. Running on Local

See instruction on GitHub

7. Links and Contact Details

Live Red Jingles Chatbot Application:

https://red-jingles-zo5w7qkf4a-ue.a.run.app/
Red Jingles API Server:

https://red-jingles.ue.r.appspot.com/docs
GitHub:

jbhv12/red-jingles (github.com)
Docker Hub:

jbhv12/red-jingles general | Docker Hub
Video Demo:

Quick Application Walkthrough

Detailed Explaination

Developers Contact Details:

Jay Bhavsar
- Email: jbhv12@gmail.com
- LinkedIn: https://www.linkedin.com/in/jbhv12/
Riya Bhavsar
- Email: riyashah0895@gmail.com
- LinkedIn: https://www.linkedin.com/in/riya-bhavsar-52237b117/