What do you do when you want someone, maybe a teammate, a designer, or a friend, to take a quick look.

Do you:

a) Push to staging?

b) Set up a tunnel?

c) Send screenshots?

d) None of the above?

If you use VS Code, there’s a faster way sitting right there: Forward Port.

It’s not a replacement for proper deployment. It won’t give you production parity. But when you just need to share your dev environment quickly, this is one of the cleanest ways to do it.

How it works:

• Start your dev app in VS Code (localhost:1111, for example).

• Open “PORTS” in the terminal of your Vs Code, click “forward a port,” and input your port number for your app.

• VS Code gives you a public URL. Share it.

That’s it. Someone else can now view your local build—no staging, no CLI tunnels, no delays.

Whenever you need quick feedback from a teammate. Want to test on your phone without pushing? Maybe you’re just trying to debug something that only happens on your end. VS Code’s Forward Port makes all of that easier. It’s perfect for sharing isolated features, getting real-time input, or previewing your app on another device without touching your CI/CD pipeline. You’re not replacing deployment, just skipping the overhead when all you need is a short-lived link to your dev box. The best part is it’s built right into VS Code. No plugins, no setup, no ngrok. Just right-click, forward the port, and share.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

If You’re Still Deploying to Share Dev Previews in 2025, You’re Doing Too Much was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Remember when AI first blew up, and everyone was scrambling to run models on their own machines? Yeah, it wasn’t fun. Between setting up dependencies, dealing with hardware limitations, and watching my laptop nearly combust under the weight of an LLM, I gave up and turned to inference APIs like most people. Running AI locally just wasn’t worth the hassle.

But now, Docker Model Runner is making that struggle a thing of the past.

What Is Docker Model Runner?

Docker Model Runner is a new feature in Docker Desktop that lets you run AI models locally without the usual headaches. It treats models as first-class Docker objects, similar to containers, images, or volumes. With a few simple commands, you can pull an AI model and run it right from your terminal.

The best part? It’s designed for efficiency, loading models into memory only when needed and running them on demand.

Why Running AI Locally Was a Nightmare

Before this, trying to run AI models locally was a disaster for most of us.

Some of us experienced:

• Hardware Struggles: If you didn’t have a powerful GPU, forget about it. Running models on a CPU was painfully slow.
• Dependency Hell: Setting up TensorFlow, PyTorch, or other frameworks was a never-ending battle with version conflicts.
• High Resource Consumption: Even if you got a model running, it could slow your entire system to a crawl.
• Privacy Concerns: Sending data to cloud inference APIs meant you had to trust third parties with sensitive inputs.

How Docker Model Runner Fixes Everything

Docker Model Runner removes all that friction by making AI models as easy to work with as Docker containers.

• No Setup Drama: No more fighting with dependencies. Just pull a model and run it.
• Hardware Acceleration: Takes advantage of your Mac’s GPU capabilities.
• Works On-Demand: Models load into memory only when needed, keeping resource usage efficient.
• Fully Local: No cloud required. Your data stays on your machine, improving privacy.

Real-World Applications

How professionals can use Docker Model Runner:

• Developers can quickly test AI capabilities locally during development.
• Data scientists can run iterations on datasets without cloud costs.
• Content creators can generate content with complete privacy.
• Teams can experiment with AI models before investing in cloud infrastructure.

For example, you could use it to build a simple chatbot application, process documents with AI assistance, or analyze data (all running locally on your Mac.)

System Requirements & Supported Features

According to the official documentation:

• Platforms: Currently available only on Docker Desktop for Mac (Apple Silicon).
• Models: Supports LLM models like Llama, Mistral, and more through the ollama engine.
• Hardware Acceleration: Uses GPU acceleration when available on supported Mac platforms.
• Model Repository: Models can be pulled from the Docker Hub registry.

Getting Started (It’s Super Easy)

1. Update Docker: Make sure you’re running Docker Desktop Desktop 4.40 and later on Mac.

2. Enable Model Runner:

It’s enabled by default in Docker Desktop; else enable, apply and restart

3. Link the CLI Plugin (for Mac users):

ln -s /Applications/Docker.app/Contents/Resources/cli-plugins/docker-model ~/.docker/cli-plugins/docker-model

4. Use the Docker CLI commands:

• Pull a Model:

docker model pull ai/llama3.1

• List available Models:

docker model list

• Run a Model with a prompt:

docker model run ai/llama3.1 "What is Docker?"

5. Remove Model:

You can remove a downloaded model from your system using the command

docker model rm ai/llama3.1

Docker Desktop also provides a built-in chat interface to interact with your models, making the process even smoother.

Integrating Docker Model Runner into Your Software Development Lifecycle

If you’re ready to build your own Generative AI application, Docker Model Runner makes it easier than ever to get started. Just started using it to power my local GenAI projects, and I can confidently say it simplifies the entire process.

To give it a try, I recommend starting with an existing GenAI app that demonstrates the potential of Docker Model Runner. Here’s how I got it running on my local machine:

1. Set up the Sample App:

Clone the repository for the sample GenAI app. Run the following command in your terminal:

git clone https://github.com/docker/hello-genai.git

2. Navigate to the App Directory:

cd hello-genai

3. Run the App:

Simply run the run.sh script to pull the selected model and start the application. It is seamless, no manual configuration needed:

./run.sh

4. Access the App:

Follow the instructions in the repository’s README. Once the app is up and running, open it in your browser.

It’s ready for use, and the interface lets you start typing prompts right away.

For me, what’s exciting is how fast the responses were. Everything was happening locally on my machine, powered by Docker and the local model. I could immediately interact with my GenAI app and see the results without waiting for cloud-based processing.

This process is incredibly simple, but the results are impactful. Docker Model Runner is helping me speed up development while keeping everything under my control. If you’re looking to create your own AI-powered applications, I highly recommend getting started with this approach!

Summary

Docker Model Runner makes working with AI models locally much easier. By removing the setup and dependency issues, it allows for smoother workflows and faster results. With Docker, you can run models directly on your machine, taking advantage of hardware acceleration where available and maintaining control over your resources. You don’t need to rely on cloud-based APIs anymore, meaning your data stays secure and local.

Whether you’re developing AI-powered applications, experimenting with models, or running analysis;

Docker Model Runner offers a more efficient and private alternative to cloud-based solutions. It makes it easier to run LLM models on your machine without the usual hassle and complexities, putting you in full control of your AI workflows.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

Thanks to Anies , Onionsman and Chigozie Nwokoye for reading drafts.

More resources:

• Docker Blog Post

Docker Model Runner: Running AI Locally Just Got Better was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my years as a DevOps engineer, I’ve learned that anticipating production challenges is the key to avoiding disaster. Recently, while working on a NestJS application, we encountered a scenario that underscored this lesson. The developers had thoroughly tested their code using a local PostgreSQL instance, and everything appeared to work flawlessly. However, when we reconfigured our development environment to mimic production by connecting to a managed PostgreSQL database (hosted on DigitalOcean), our application refused to connect and immediately threw this error:

ERROR [TypeOrmModule] Unable to connect to the database. Retrying...
Error: self-signed certificate in certificate chain
    at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34)

This wasn’t a mistake in our code; but a direct consequence of managed databases enforcing SSL by default — a critical security measure that local, self-hosted databases often bypass.

Understanding the Root Cause

The error occurred because Node.js did not trust the SSL certificate provided by the managed database.

Most cloud providers whether it’s AWS RDS, Azure Database, or DigitalOcean use their own Certificate Authority (CA) to sign database certificates. These custom CAs are not included in Node.js’s default trusted certificate store, causing SSL validation failures when attempting to connect securely.

Why You Shouldn’t Disable SSL Verification

A common but dangerous workaround is to disable SSL verification entirely by setting:

NODE_TLS_REJECT_UNAUTHORIZED=0

However, this is a security risk and effectively disables certificate validation, leaving your application vulnerable to man-in-the-middle attacks.

Instead, a better approach is to explicitly provide Node.js with the correct CA certificate using the NODE_EXTRA_CA_CERTS environment variable.

The Solution: Using NODE_EXTRA_CA_CERTS

The NODE_EXTRA_CA_CERTS environment variable allows you to extend the list of trusted certificate authorities without modifying your application code.

Step 1: Obtain the CA Certificate

Each cloud provider offers its CA certificate for download. Here’s where to find them:

• DigitalOcean: Available under the database cluster’s “Connection Details”
• AWS RDS: Regional CA certificates can be downloaded from AWS documentation
• Azure Database: Downloadable from Microsoft’s official documentation

Save the CA certificate to a secure location on your local machine or server.

Step 2: Set the NODE_EXTRA_CA_CERTS Environment Variable

Before running your application, set the environment variable to point to the downloaded CA certificate.

For Linux/macOS:

export NODE_EXTRA_CA_CERTS=/path/to/ca-certificate.crt

For Windows (Command Prompt):

set NODE_EXTRA_CA_CERTS=C:\path\to\ca-certificate.crt

For Windows (PowerShell):

$env:NODE_EXTRA_CA_CERTS="C:\path\to\ca-certificate.crt"

Step 3: Run Your Application

Now, when you start your application:

npm run start

Node.js will use the provided CA certificate to establish a secure connection with the database.

Permanent Configuration for Different Environments

1. For Development Environments:

To avoid manually setting the variable every time, add it to your .env file:

NODE_EXTRA_CA_CERTS=/path/to/ca-certificate.crt
DATABASE_URI=postgresql://username:password@hostname:port/database?sslmode=require

2. For Production Deployments:

Docker Containers

Modify your Dockerfile to copy the CA certificate and set the environment variable:

COPY ./ca-certificates/database-ca.crt /etc/ssl/certs/
ENV NODE_EXTRA_CA_CERTS=/etc/ssl/certs/database-ca.crt

Kubernetes Deployment

If you are deploying in Kubernetes, update your deployment manifest to mount the CA certificate:

env:
  - name: NODE_EXTRA_CA_CERTS
    value: /etc/ssl/certs/database-ca.crt
volumeMounts:
  - name: ssl-certs
    mountPath: /etc/ssl/certs/database-ca.crt
    subPath: database-ca.crt
volumes:
  - name: ssl-certs
    configMap:
      name: database-ca-cert

Systemd Service Configuration

For applications managed by systemd, add the environment variable to the service file:

[Service]
Environment="NODE_EXTRA_CA_CERTS=/etc/ssl/certs/database-ca.crt"

Comparing Different Approaches

Here’s how NODE_EXTRA_CA_CERTS compares to alternative solutions:

As seen above, NODE_EXTRA_CA_CERTS is the best balance between security, maintainability, and ease of implementation.

Troubleshooting Common Issues

If you still experience SSL errors after setting NODE_EXTRA_CA_CERTS, check the following:

1. Verify the certificate path: Ensure the path to the CA certificate is correct and accessible.
2. Check the certificate format: It should be in PEM format (.crt or .pem).
3. Intermediate certificates: Some cloud providers use intermediate CAs that must also be included.
4. Shell/environment variable scope: Ensure NODE_EXTRA_CA_CERTS is set in the correct session.

Conclusion

This method is beneficial for teams working with frameworks like NestJS, Express, or Fastify, where database connection configurations can be complex.

Leveraging NODE_EXTRA_CA_CERTS instead of NODE_TLS_REJECT_UNAUTHORIZED, ensures your application maintains strong security without unnecessary code changes or risky workarounds.

With proper SSL handling, you can eliminate connectivity issues, prevent last-minute deployment failures, and deploy with confidence — whether you’re running locally, in staging, or production.

A well-configured environment is the foundation of a secure, scalable, and resilient application. By adopting these best practices, your NestJS applications will be ready to handle real-world deployments while maintaining robust security and reliability.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

Thanks to Elisha Ukpong and Onionsman for reading drafts.

Fixing “Self-Signed Certificate in Certificate Chain” Error in NestJS with Managed Databases was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

What should be a straightforward process often turns into a comedy of errors—except nobody’s laughing when production data is at stake.

I was migrating a PostgreSQL database from a self-hosted server to a managed service.

Unlike self-hosted PostgreSQL, a managed database service automates backups, scaling, security, and maintenance, reducing operational overhead while ensuring high availability, performance, and reliability.

Simple plan:

• Dump the database.
• Push it to the new managed instance.
• Move on with my life.

PostgreSQL, of course, had other ideas.

If you’re about to migrate your database, buckle up. Here’s how to do it right—without breaking security, your patience, or your production environment.

Step 1: Dump the Database (And Hope Your Versions Match)

I started by running pg_dump on my local machine to pull the database from the remote server:

pg_dump -h [SOURCE_HOST] -p 5432 -U [DB_USER] -W -d [DB_NAME] -f backup.sql

(You’ll be prompted for the password.)

Immediately, PostgreSQL smacked me with:

pg_dump: error: server version: 15.7; pg_dump version: 14.13
pg_dump: error: aborting because of server version mismatch

PostgreSQL refuses to dump databases using an older client version than the server.

Fix: Upgrade Your PostgreSQL Client

Since my database was running PostgreSQL 15.7, I upgraded my local client:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt update
sudo apt install -y postgresql-client-15

With that, pg_dumpworked without issues.

Step 2: Restoring the Dump to a Managed PostgreSQL Database

With my backup file ready, I ran:

psql -h [MANAGED_DB_HOST] -p [PORT] -U [DB_USER] -W -d [DB_NAME] < backup.sql

And PostgreSQL laughed in my face, as if to say, "Who do you think you are?”

psql:backup.sql:1389: ERROR: must be able to SET ROLE "postgres"

Why? ,

With self-hosted, I had full control and could assume the postgres role but many managed services restrict direct access to the postgres superuser role.

My dump file contained lines like:

ALTER TABLE my_table OWNER TO postgres;

But my managed database didn’t allow a postgres user with superuser privilege. They create a different default admin role that lacks full privileges.

Fix: Change Database Ownership Before Restoring

To sidestep this restriction, I replaced all OWNER TO postgres; occurrences in the dump file with my actual database user with the command:

sed -i ‘s/OWNER TO postgres;/OWNER TO [YOUR_DB_USER];/g’ backup.sql

After that, the restore command worked perfectly. You may then switch your application Database URL to point to the new managed service.

Security Warning: Your Backup File is a Goldmine

Your backup.sql file likely contains credentials, schema details, and user permissions. Treat it like a password.

How to Secure It:

• Restrict file access:

chmod 600 backup.sql

• Never commit it to Git.
• Store it securely and delete it after migration.

Side Note: What If External Connections Are Blocked?

I didn’t run into this as this was earlier taken care of, but you might. If you get:

psql: error: connection to server at "[MANAGED_DB_HOST]" (192.168.x.x), port 25060 failed: 
FATAL: no pg_hba.conf entry for host "[YOUR_IP]", user "[YOUR_DB_USER]", database "[YOUR_DB_NAME]"

Your managed database is blocking external connections.

Fix: Whitelist Your IP—Securely

1. Get your public IP:

curl ifconfig.me

2. Go to your database provider’s settings and add your IP to the allowlist.

3. Only allow trusted IPs—never open access to 0.0.0.0/0. Unless, of course, you enjoy security nightmares.

Final Lesson

This should take 15 minutes. Instead, I had to:

• Upgrade my PostgreSQL client.
• Modify ownership settings to avoid permission issues.
• Work around managed database restrictions.

Hence, these key takeaways are worthy of note:

1. Version compatibility is everything. Make sure pg_dump and psql match the PostgreSQL server version before you start.
2. Managed services have restrictions—superuser access is off limits, so expect ownership issues.
3. Adjust the dump file when needed—replace OWNER TO postgres; with your actual database username.
4. Secure your connections—never allow unrestricted external access (0.0.0.0/0).
5. Back up your backup—just in case.
6. Secure your backup file—encrypt it, never push it to git, restrict access, and delete it after migration.

How I Ensured Data Integrity During Migration

A major concern was preventing writes to the database while migration was in progress. Two approaches usually work:

Option 1: Logical Replication (For Zero Downtime)

For large-scale, mission-critical databases, I’ve used logical replication in the past. This allows continuous syncing between the source and target database, ensuring a seamless switchover as I would need to :

1. Set up a replication slot on the source database.

2. Configure the managed database as a subscriber.

3. Let replication run while the application continues operating.

4. Switch over seamlessly once everything is synced.

This is the best option when downtime isn’t acceptable.

Option 2: Maintenance Mode (What I Used Here)

For this migration, I opted for a faster, simpler approach that involved a short, controlled downtime:

1. Pre-migration notice – Users were informed in advance that the system would enter maintenance mode.

2. Activated maintenance mode – Prevented new writes while I dumped and restored the database.

3. Ran the migration immediately – With no active writes, the process was clean and efficient.

4. Switched the application to the new database – Once the restore was complete, I pointed the app to the new managed database and disabled maintenance mode.

This ensured a minimal disruption, rather than an actual downtime where users would see errors or broken functionality.

Choosing the Right Approach

• Use logical replication when you need true zero downtime and can set up continuous syncing.
• Use maintenance mode when a short, controlled downtime is acceptable for a simpler, cleaner migration.

I’ve used both methods in different scenarios, and choosing the right one depends on your system’s needs.

Migrating databases isn’t supposed to be a fight, but PostgreSQL has a way of making sure you earn your victory. If you find yourself in the middle of an unexpected battle, just remember: the database isn’t being difficult — it’s just making sure you know what you’re doing.

PostgreSQL enforces best practices for a reason. Follow these steps, and your migration will be seamless, secure, and frustration-free.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

A few years ago, a small SaaS startup launched with a great idea — an AI-powered personal finance assistant. The founders were excited, and their first instinct was to build for scale. They provisioned redundant cloud resources, assuming they would need them soon. They were ready for millions of users.

By the end of their first quarter, they had spent more on infrastructure than they had earned in revenue. Except, they didn’t have millions of users. They had a few hundred. Yet their cloud bill was climbing north of $1,000 per month. Before they had a chance to iterate on their product-market fit, they were drowning in infrastructure costs. Within a year, they shut down.

This is a common story — that plays out in different variations across the startup world. Founders and engineers often over-engineer their infrastructure based on hypothetical future needs, rather than present realities.

As a DevOps and infrastructure engineer, I have repeatedly seen this mistake: teams spend excessive time and resources designing for massive scalability when they haven’t even validated their core business model. In this article, I will share important lessons I’ve learned throughout my journey and how to strike the right balance between scalability and efficiency.

The truth is, you don’t need to scale until your business demands it.

The High Cost of Premature Scaling

AWS, GCP, and Azure provide powerful infrastructure solutions, but they come at a steep price. When teams configure auto-scaling groups, distribute workloads across multiple availability zones, and implement advanced caching strategies before their traffic justifies it, they introduce unnecessary complexity and cost.

Where the Costs Add Up

1. Cloud Providers Are Expensive: Distributed architectures come with increased networking, storage, and data transfer costs.

2. Overprovisioned Resources Drain Budget: Teams often allocate excessive computing power without fully utilizing it, leading to wasted spend.

3. Operational Complexity Kills Agility: Managing a multi-cloud, multi-region setup requires dedicated DevOps expertise, adding overhead.

Scaling Strategies: Picking the Right Approach

Scaling is a fundamental concept in software architecture, referring to a system’s ability to handle increased load. Scaling isn’t one-size-fits-all. Businesses need to choose the right strategy based on demand — application specific needs and growth patterns. Here are the three main approaches:

• Vertical Scaling (Scaling Up): Enhancing the capacity of a single server by adding more resources, such as CPU or RAM. It’s like upgrading a computer to make it more powerful.
• Horizontal Scaling (Scaling Out): Adding more servers to distribute the load. This approach increases capacity by expanding the number of machines working together.
• Diagonal Scaling (A Balanced Approach): Diagonal scaling is a flexible approach that combines both vertical and horizontal scaling, adjusting dynamically based on current demand. Instead of choosing one strategy upfront, it starts with vertical scaling — adding more CPU, memory, or storage to a single machine until it reaches its limit. Once further growth is needed, it shifts to horizontal scaling by distributing workloads across multiple instances. For example, a business might begin by upgrading its database server, but as traffic grows, it can introduce read replicas and load balancing to manage increasing queries efficiently.

The key advantage of diagonal scaling is adaptability — it allows infrastructure to grow when demand rises and scale down when demand drops, ensuring cost-efficiency without unnecessary complexity.

A Smarter Approach: When to Use the Right Scaling Strategy

Instead of over-engineering infrastructure and blindly deploying a distributed system from the beginning, companies should start simple and scale incrementally, teams should optimize their architecture based on actual usage patterns:

1. Use Vertical Scaling First: If your application is CPU/memory-bound and traffic is predictable, upgrading to a larger instance is usually the simplest and most cost-effective solution.

2. Introduce Horizontal Scaling When Needed: If you’re hitting consistent performance bottlenecks due to concurrent traffic spikes, then adding more instances makes sense.

3. Monitor Before Scaling: Performance bottlenecks should be analyzed first — sometimes caching, query optimization, or asynchronous processing can eliminate the need for immediate scaling.

For applications with fewer than 1,000 monthly users, a monolithic architecture with vertical scaling is often one of the best approach.

Why Monoliths Work Better at Early Stages

Many startups jump straight into microservices, thinking it’s the modern way to build software. However, microservices introduce communication overhead, deployment complexity, and operational challenges. A well-structured monolith is often easier and cheaper to maintain early on as it provides:

1. Lower Infrastructure Cost: A single well-optimized instance is cheaper than running multiple small instances with distributed overhead.

2. Simplified Debugging & Maintenance: Fewer moving parts mean fewer things breaking at scale.

3. Easier to Iterate: Early-stage applications require rapid development cycles, not excessive infrastructure.

Practical Steps to Scale the Right Way

1. Keep it Monolithic Initially: Until you hit scale bottlenecks, avoid microservices and distributed patterns.

2. Optimize Before Scaling: Improve database queries, implement caching (Redis, Memcached), and optimize code efficiency before provisioning more resources.

3. Benchmark Your Limits: Use load testing to define at what threshold your infrastructure needs to scale.

“But I Don’t Want to Configure Things Twice!”

A common argument against starting small is that reconfiguring for scale later requires extra work. However, this thinking ignores two critical realities:

1. Your Scaling Needs Will Evolve Unpredictably: Designing prematurely for a million users results in unnecessary complexity.
2. Modern Migration Is Easier Than Ever: Tools like Terraform, Kubernetes, and cloud-native databases simplify infrastructure changes.

Investing in massive scalability before demand exists is like renting a stadium before you’ve formed a local football team.

Is Serverless Really Cost-Effective?

Serverless computing is often marketed as an affordable way to scale, but poor configurations can lead to unexpected costs. Misconfigured AWS Lambda, Firebase, or Vercel functions have resulted in five-figure invoices due to:

• Execution Duration Costs: Poorly optimized functions that run longer than necessary drive up costs.
• Concurrency Limits and Scaling Behavior: Auto-scaling adds more instances, each incurring additional costs.
• Networking Costs: Frequent external database calls lead to excessive cross-region networking charges.

Serverless isn’t inherently bad, but it requires careful tuning. It’s not always the cheapest solution, especially when running continuously.

The Importance of Building for Scalability — Without Prematurely Scaling

While premature scaling is a mistake, engineers should still design applications for future scalability without introducing unnecessary overhead.

How to Design for Future Scaling

• Decouple Core Logic: Structuring business logic modularly makes migrating to microservices easier.
• Choose Databases That Scale: PostgreSQL, MySQL, and other relational databases can handle significant scale if architected properly with indexing, replication, and partitioning strategies.
• Implement Caching from Day One: Using a caching layer like Redis significantly reduces the need for excessive scaling by offloading repeated queries.
• Use Feature Flags and Modular Deployment: This enables incremental migrations without massive rework.
• Avoid Cloud Vendor Lock-in: Open standards for databases, messaging queues, and storage provide long-term flexibility.

When to Actually Scale

There is a right time to move beyond vertical scaling and invest in horizontal scaling, distributed databases, and containerized workloads. That time comes when:

• Traffic consistently exceeds 10,000+ monthly users, and performance bottlenecks arise despite optimizations.
• A single server is no longer enough due to CPU/memory constraints, even after vertical scaling.
• Your team requires independent deployments, and the monolith slows down development velocity.
• Your business model is validated, and you need high availability guarantees for paying customers.

Conclusion: Scale When Your Business Scales

Before designing for millions of users, ask yourself: Do I even have a thousand yet?

Many startups fail because they focus on enterprise-scale infrastructure before validating their business model.

So, as a business, what is the best infrastructure that won’t cost a lot but can scale when demand rises or falls?

The answer lies in diagonal scaling because the best infrastructure balances cost and scalability:

• Start lean with minimal but efficient resources.
• Optimize vertically first — improve performance before adding more machines.
• Scale horizontally only when necessary.
• Use automation to scale dynamically, avoiding unnecessary costs.

Scaling should be a response to growth, not a prediction of it. Businesses that scale too soon waste money and slow down development. The key is to build infrastructure based on real demand, not future assumptions.

By balancing lean infrastructure with scalable software design and actual business growth, engineers and startups can manage costs effectively while positioning themselves for future success.

Additional tools and resource ➡️ Visit StartupStash
Zendesk is giving $75,000 in credits and perks for startups! ➡️ Apply Now!

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Have you experienced infrastructure scaling challenges? Let’s connect and discuss: LinkedIn | Github

Strategic Infrastructure Scaling: Don't Scale What Isn't Growing was originally published in Startup Stash on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I joined the company, I anticipated the usual hurdles — getting familiar with systems, understanding workflows, and aligning with the team’s goals. What I didn’t expect was entering straight into a digital time capsule, surrounded by outdated servers running end-of-life (EOL) versions of Ubuntu.

As an infrastructure engineer, my job typically revolves around building and maintaining robust, scalable, and — most importantly — up-to-date systems. But sometimes, you inherit problems that aren’t yours, to begin with, and in this case, it was a client’s legacy system that would soon become my headache, or as I like to call it, “my unexpected adventure.”

The client had been running servers on a version of Ubuntu so outdated, it practically belonged in a museum. The moment I tried to update the server, it hit me: I was dealing with a legacy system way past its prime. The repositories were gone, updates were a distant memory, and security vulnerabilities were waiting to be exploited. Though the legacy system was inherited, ensuring its stability and security was now our challenge to overcome.

So, what followed was not just a technical fix but a lesson in patience, persistence, and understanding the importance of proactive infrastructure management. Here’s how I transformed a legacy disaster into a secure, stable system that the client could rely on for years to come.

Why Running Non-LTS Versions is a Bad Idea

Before we discuss how I solved this particular issue, let’s take a step back and ask: Who the hell provisions servers that aren’t LTS?

You’d be amazed at how often this happens, especially when it’s not immediately obvious why it matters. The primary reason you should avoid running non-LTS (non-Long Term Support) versions of Ubuntu — or any Linux distribution, for that matter — on production servers is that they lack the critical support and security updates needed to keep systems stable and secure.

While non-LTS versions may seem appealing because they offer the latest features and updates, they come with a major downside: shorter support windows.

Typically, non-LTS versions (Non-Long Term Support release versions) are supported for only 9 months, which means after that, security patches and software updates are no longer provided. In contrast, LTS versions offer 5 years of support, which includes security updates and patches, making them far more suitable for production environments.

Running a non-LTS version can expose your infrastructure to various risks:

1. Security Vulnerabilities

Non-LTS versions stop receiving security updates as soon as they reach their end of life. Without these critical patches, your system becomes an easy target for attackers exploiting known vulnerabilities. This can compromise your entire infrastructure.

2. Stability Issues

Non-LTS versions lack the long-term maintenance and refinement of LTS releases. As a result, you may encounter bugs and performance issues that are never fixed, leading to instability in critical environments.

3. Compatibility Challenges

Over time, third-party applications, libraries, and tools may stop supporting non-LTS versions. This incompatibility can disrupt workflows and require time-consuming workarounds or migrations.

4. Dependency Problems

Running updates on non-LTS versions often fails due to unavailable or unsupported repositories. This can leave your server with outdated and broken dependencies, further complicating maintenance and upgrades.

5. Lack of Vendor Support

When using a non-LTS version, you forfeit access to vendor assistance for troubleshooting, bug fixes, and patches. In a production environment, this lack of support can result in prolonged downtime and increased operational costs.

In summary, LTS is the only practical, secure, and stable option for production servers. Choosing non-LTS versions for your server setup may seem like a shortcut, but it’s a mistake that will lead to more pain than it’s worth.

The Problem: Outdated Servers Running an End-of-Life OS

The server was running an Ubuntu version that had already reached its end-of-life (EOL). The repositories for the distribution had been shut down, and I was attempting to run

sudo apt update

Error Output:

Hit:1 https://repos.insights.digitalocean.com/apt/do-agent main InRelease
Ign:2 http://mirrors.digitalocean.com/ubuntu mantic InRelease                  
Ign:3 http://security.ubuntu.com/ubuntu mantic-security InRelease              
Ign:4 http://mirrors.digitalocean.com/ubuntu mantic-updates InRelease          
Hit:5 https://repos-droplet.digitalocean.com/apt/droplet-agent main InRelease  
Ign:6 http://mirrors.digitalocean.com/ubuntu mantic-backports InRelease        
Err:7 http://mirrors.digitalocean.com/ubuntu mantic Release                    
  404  Not Found [IP: my server ip address]
Err:8 http://security.ubuntu.com/ubuntu mantic-security Release                
  404  Not Found [IP: my server ip address]

The output described a series of errors indicating missing repositories. The most glaring was the error about the “404 Not Found” status for the package sources. It was clear: the server was not only out of date but had become a ticking time bomb for potential vulnerabilities.

The Action: The Path to Recovery

Step 1: Identify the OS Version and Plan the Upgrade

First, I identified the exact version of Ubuntu running on the server:

lsb_release -a

Output:

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 23.04
Release:        23.04
Codename:       mantic

Once I confirmed the system was running a non-LTS version, I recognized the need to upgrade to a supported LTS version.

Step 2: Back Up the System

Before making any changes, I created a full backup to ensure recovery options if something went wrong

sudo rsync -av --exclude=/proc --exclude=/sys --exclude=/tmp / /backup

Step 3: Update Repository Sources

Since the current release was no longer supported, I updated the sources.list file to point to the old-releases archive:

1. Open the file for editing:

sudo nano /etc/apt/sources.list

2. Replace instances of the current mirrors with the old-releases.ubuntu.com URLs.

In the case of the mantic (23.04) release, you would replace your existing sources with this:

deb http://old-releases.ubuntu.com/ubuntu mantic main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu mantic-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu mantic-security main restricted universe multiverse

3. Save and exit (Ctrl+O, Enter, Ctrl+X).

With the old-releases repository, I could access the required packages and patches needed to proceed with the upgrade.

After updating the sources, I refreshed the package list

sudo apt update
sudo apt upgrade -y

Step 4: Enable LTS Upgrades

I modified the release-upgrade configuration to allow upgrades to LTS versions:

sudo nano /etc/update-manager/release-upgrades

Ensure the Prompt line reads:

Prompt=lts

Save and exit.

Step 5: Perform the Upgrade

I initiated the upgrade process:

sudo do-release-upgrade

P.S: If no new LTS release is detected, add the -d flag to force the upgrade:

sudo do-release-upgrade -d

During the upgrade, most of the prompts are self-explanatory, carefully read them and proceed. Once the upgrade is completed, Reboot the system when asked.

Step 6: Post-Upgrade Cleanup

After completing the upgrade, I cleaned up unnecessary packages:

sudo apt autoremove -y

Step 7: Verify the Upgrade

To confirm the upgrade, I checked the kernel and OS version again with uname -mrs and lsb_release -a:

For good measure, I just checked to make sure I had the latest of every package:

sudo apt update
sudo apt upgrade -y

This came back all clear!

Step 8: Security Audit

To ensure the server was secure post-upgrade, I ran a security audit using Lynis:

echo "deb http://packages.cisofy.com/community/lynis/deb/ stable main" | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 86B72ED56D4F3D2B
sudo apt update
sudo apt install lynis -y
sudo lynis audit system

When you run sudo lynis audit system, Lynis will execute various checks and provide recommendations related to system security, configurations, and vulnerabilities. It will output a detailed report in the terminal and store the logs in /var/log/lynis.log.

The Aftermath: A Secure, Stable System

Inheriting a legacy system running an unsupported version of Ubuntu was both a challenge and an opportunity to demonstrate the importance of proactive infrastructure management. The outdated server posed significant risks: missing security updates, unstable infrastructure, and compatibility issues — all of which reinforced a crucial lesson: non-LTS versions have no place in production environments.

The solution required a methodical approach. From identifying the problem and backing up data to updating repository sources and upgrading to a stable LTS release, each step was crucial in restoring the system’s integrity.

The result? A secure, robust, and scalable solution ready to support the client’s future needs with confidence.

This experience is a stark reminder that running non-LTS systems may seem convenient initially, but it’s a gamble fraught with risk. The costs — security vulnerabilities, downtime, and operational headaches — far outweigh any perceived benefits. For infrastructure managers, the message is clear: don’t wait for vulnerabilities or failures to force your hand.

Take charge of your systems before they take control of you. Adopt LTS versions, conduct regular system audits, and prioritize security. Future-proof your infrastructure now, because in the ever-evolving world of tech, staying current isn’t just an option; it’s a necessity.

Ready to secure your systems and safeguard your infrastructure? Start by auditing your servers today — your future self will thank you.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

Thanks to Elisha Ukpong and Onionsman for reading drafts and making suggestions.

Why Running Non-LTS Ubuntu Servers Is a Risk: was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In modern web infrastructure, proxies play a crucial role in managing traffic, enhancing security, and improving performance. But before going deep into reverse proxies, let’s first define what a proxy server is and how it works.

What Is a Proxy Server?

A proxy server is an intermediary between a client (like your browser) and the internet. It handles requests on behalf of the client and then forwards them to the destination server. When the server responds, the proxy sends the data back to the client. This helps with:

• Security: The proxy can hide the client’s real IP address.
• Performance: Proxies can cache data to reduce response times.
• Control: Proxies can filter content or monitor traffic.

Forward Proxy vs. Reverse Proxy

Now that we understand what a proxy is, let’s look at the two common types: forward proxy and reverse proxy.

Forward Proxy

A forward proxy sits between the client and the internet. It’s used primarily by clients (like browsers) to reach websites. Some common use cases include:

• Hiding IPs: A forward proxy can mask the client’s IP address, offering anonymity.
• Content Filtering: It can block access to certain websites, commonly used in corporate environments.
• Caching: It stores frequently accessed content to reduce traffic and speed up browsing.
• Common use cases: Anonymizing traffic, bypassing firewalls, accessing geo-restricted content.

For example, in a corporate network, employees’ internet traffic goes through a forward proxy, which filters out harmful websites and hides the employees’ IP addresses.

Reverse Proxy

A reverse proxy, on the other hand, serves as an intermediary between the client and your backend servers. When a client makes a request, the reverse proxy forwards it to the appropriate server. Some key benefits of a reverse proxy include:

• Load Balancing: Distributes incoming traffic across multiple servers, preventing any one server from becoming overwhelmed.
• SSL Termination: Handles the encryption and decryption of SSL/TLS traffic, offloading this task from your backend servers.
• Security: Protects your backend servers by masking their identities from the outside world.
• Simplified Infrastructure: With a reverse proxy, clients don’t need to know about the backend servers. The proxy handles requests and routes them to the appropriate server, reducing the complexity of your infrastructure.
• Caching: Reverse proxies can cache responses from backend servers, reducing the load on the servers and speeding up response times for frequently accessed content.
• Common use cases: Load balancing, caching, security, and hiding server identities.

The primary difference is that while a forward proxy aids the client, a reverse proxy helps the server infrastructure. With a reverse proxy, clients interact with a single entry point, which then decides how to route the request to the appropriate server.

Why Choose NGINX or Traefik for Reverse Proxy?

Two of the most popular solutions for reverse proxies are NGINX and Traefik. Both offer robust features, but they cater to different use cases.

NGINX

NGINX is known for its performance, flexibility, and scalability. It’s a popular choice for high-traffic websites and complex web applications. NGINX provides extensive configuration options, allowing you to fine-tune how your reverse proxy behaves.

Key Features of NGINX:

• Manual Configuration: NGINX requires manual setup, giving you fine-grained control over your reverse proxy.
• Load Balancing: NGINX supports various load balancing algorithms like round-robin and least-connections.
• SSL Termination: NGINX can handle SSL/TLS encryption and decryption, offloading these tasks from backend servers.
• Caching: You can configure NGINX to cache responses for even faster subsequent requests.

Setting Up NGINX as a Reverse Proxy

1. Install NGINX:

sudo apt update
sudo apt install nginx

2. Basic Reverse Proxy Configuration: Create a configuration file (e.g., /etc/nginx/sites-available/my-site.conf) with the following content:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://your-backend-server:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. Test and Reload NGINX:

sudo nginx -t
sudo systemctl reload nginx

Traefik

Traefik is designed for dynamic, cloud-native environments such as microservices and containerized applications. It automatically discovers services and adapts to changes in real time, making it ideal for modern DevOps environments.

Key Features of Traefik:

• Automatic Service Discovery: Traefik automatically detects services running in containers (e.g., Docker or Kubernetes) without manual configuration.
• Dynamic Configuration: It seamlessly adapts to changes in infrastructure, which is perfect for microservices that are frequently deployed and updated.
• SSL/TLS Automation: Traefik integrates directly with Let’s Encrypt, automatically generating and renewing SSL certificates.

Setting Up Traefik with Docker

1. Configure Traefik in Docker: Create a docker-compose.yml file with the following configuration:

version: '3'
services:
  traefik:
    image: traefik:v2.5
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--entryPoints.web.address=:80"
      - "--entryPoints.websecure.address=:443"
    ports:
      - "80:80"
      - "443:443"

2. Configure SSL with Let’s Encrypt: Add labels to enable automatic SSL;

labels:
  - "traefik.http.routers.web.rule=Host(example.com)"
  - "traefik.http.routers.web.tls=true"
  - "traefik.http.routers.web.tls.certresolver=myresolver"

3. Define Certificate Resolver:

certificatesResolvers:
  myresolver:
    acme:
      email: your-email@example.com
      storage: /letsencrypt/acme.json
      httpChallenge:
        entryPoint: web

Traefik excels in dynamic and containerized environments, automatically adapting to the lifecycle of services as they are launched or stopped.

NGINX vs. Traefik: Which One Should You Choose?

Conclusion

Proxies play a pivotal role in modern web infrastructure by acting as intermediaries between clients and servers. They enhance security, improve performance, and provide greater control over traffic management.

• Forward Proxies: Primarily serve clients by masking IPs, filtering content, and caching data.
• Reverse Proxies: Aid server infrastructures by enabling load balancing, SSL termination, and protecting backend servers.

When it comes to reverse proxies:

• NGINX is the go-to solution for high-traffic, traditional environments, offering extensive customization, caching, and load balancing options.
• Traefik excels in dynamic, containerized ecosystems, automating service discovery and SSL setups, making it a favorite for modern DevOps and cloud-native architectures.

Choosing the right proxy depends on your specific needs, whether you’re managing a traditional web application or scaling a microservices-based infrastructure. Proxies are indispensable for building secure, efficient, and scalable systems.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

In this article, we’ll walk you through configuring Caddy (A powerful, easy-to-use web server that automatically handles SSL certificates and reverse proxying ) to use an external SSL/TLS certificate from a commercial Certificate Authority (CA).

While Caddy can handle automatic certificate management with Let’s Encrypt, there are situations where you may need to use a certificate provided by a third-party CA.

We’ll demonstrate how to deploy and configure this type of certificate with Caddy, including the necessary steps to ensure it works correctly.

We’ll automate the setup using Ansible ( A popular automation tool for configuring systems and deploying applications with simple, human-readable YAML files ) to simplify and streamline the process for production environments.

Prerequisites

Before you begin, ensure that you have:

1. A valid SSL/TLS certificate and corresponding private key from your CA.
2. Ansible installed for automation.
3. Root or sudo privileges on the server to install packages and modify system configurations.

Step 1: Preparing Your Certificate Files

When you receive an SSL certificate from a commercial Certificate Authority, it often consists of multiple files, such as:

1. The leaf certificate (your server’s certificate) — usually ends with .crt or .pem
2. The intermediate certificate (which bridges the trust between your leaf certificate and the root certificate) — ends with .crt or .pem
3. The private key associated with the leaf certificate — usually ends with .key

Sometimes these certificates are provided separately, and sometimes in a single file (full chain). In most cases, the leaf certificate needs to be combined with the intermediate certificate to form the full certificate chain. This ensures that browsers and other clients can validate the entire trust path, from the root CA to your leaf certificate.

Step 2: Setting Up Ansible to Automate the Configuration

For this guide, we’ll use Ansible to automate the deployment of your SSL certificate onto the Caddy server. The Ansible playbook will copy your certificate files, concatenate the leaf and intermediate certificates (if needed), and configure Caddy to use them.

Here is an example Ansible Playbook that automates the process of installing dependencies, configuring Caddy, and deploying the certificate:

- hosts: all
  become: yes
  tasks:
    - name: Update apt packages
      become: true
      apt:
        update_cache: yes
    
    - name: Install Caddy and fail2ban
      become: true
      apt:
        pkg:
          - caddy
          - fail2ban

    - name: Copy server certificate file (example.com.crt)
      copy:
        src: ../templates/example.com.crt
        dest: /etc/ssl/certs/example.com.crt
        mode: ‘0644'

    - name: Set correct ownership for the certificate file
      file:
        path: /etc/ssl/certs/example.com.crt
        owner: caddy
        group: caddy
        mode: ‘0644'

    - name: Copy intermediate certificate (DigiCertCA.crt)
      copy:
        src: ../templates/DigiCertCA.crt
        dest: /etc/ssl/certs/DigiCertCA.crt
        mode: ‘0644'

    - name: Set correct ownership for the intermediate certificate
      file:
        path: /etc/ssl/certs/DigiCertCA.crt
        owner: caddy
        group: caddy
        mode: ‘0644'

    - name: Concatenate server certificate and intermediate certificate to form a full chain
      shell: "cat /etc/ssl/certs/example.com.crt /etc/ssl/certs/DigiCertCA.crt > /etc/ssl/certs/example.com_fullchain.crt"
      args:
        creates: /etc/ssl/certs/example.com_fullchain.crt

    - name: Copy private key file (example.com.key)
      copy:
        src: ../templates/example.com.key
        dest: /etc/ssl/private/example.com.key
        mode: ‘0600'

    - name: Set correct ownership for the private key file
      file:
        path: /etc/ssl/private/example.com.key
        owner: caddy
        group: caddy
        mode: ‘0600'

    - name: Set correct permissions for the /etc/ssl/private directory
      file:
        path: /etc/ssl/private
        owner: caddy
        group: caddy
        mode: ‘0750'

    - name: Copy Caddy configuration file
      template:
        src: ../templates/Caddyfile
        dest: /etc/caddy/Caddyfile

    - name: Format Caddyfile
      ansible.builtin.shell: /usr/bin/caddy fmt --overwrite /etc/caddy/Caddyfile

    - name: Reload Caddy service to apply changes
      systemd:
        name: caddy
        state: reloaded

Step 3: Explanation of Key Steps

1. Copying Certificate Files
After the installation, we begin by copying the necessary certificate files to their proper locations. These files typically include:

• Leaf Certificate (example.com.crt): This is the public certificate issued for your domain.
• Intermediate Certificate (DigiCertCA.crt): This bridges the trust between your leaf certificate and the root certificate.
• Private Key (example.com.key): This is the private key that matches your leaf certificate.

These files are placed in the appropriate directories (/etc/ssl/certs and /etc/ssl/private) with correct file permissions to ensure proper access control. The playbook will set ownership to the caddy user, which is important for security.

2. Concatenating the Full Chain
In most cases, the leaf certificate needs to be combined with the intermediate certificate to form a full certificate chain. This ensures that clients can trace the certificate back to a trusted root authority.

Here’s the command used to concatenate the certificates:

cat /etc/ssl/certs/example.com.crt /etc/ssl/certs/DigiCertCA.crt > /etc/ssl/certs/example.com_fullchain.crt

The full chain includes the leaf certificate first, followed by the intermediate certificate. This order is important because it ensures the correct certificate trust path.

3. Configuring Caddy with the Certificates
Next, the template Caddyfile is configured to use the full certificate chain and the private key. The Caddyfile is a simple configuration file where we specify the certificate locations.

Here’s the relevant section in the Caddyfile:

example.com {
    tls /etc/ssl/certs/example.com_fullchain.crt /etc/ssl/private/example.com.key
    reverse_proxy localhost:8080
}

The tls directive tells Caddy to use the full chain certificate and the private key for SSL/TLS encryption. The reverse_proxy directive forwards traffic to your application running on localhost:8080.

4. Reloading Caddy

Finally, the playbook reloads the Caddy service using systemd to apply the new configuration and certificate changes:

- name: Reload Caddy service to apply changes
  systemd:
    name: caddy
    state: reloaded

Step 4: Running the Playbook

To apply the changes, you’ll run the Ansible playbook on your server with the following command:

ansible-playbook -i your_inventory_file configure_caddy.yml

This will automate the entire process, including copying the certificate files, setting up Caddy, and reloading the service.

Step 5: Validation via Command Line

After deploying the certificate using Ansible, you can use the openssl command to validate the expiration of the SSL certificate from your local machine or a remote server:

1. Using openssl to Check SSL Expiration:

This command will connect to your server and display the expiration date of the SSL certificate:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

Output: The command will return a line like this:

notAfter=Dec 31 23:59:59 2024 GMT

Conclusion

In this article, we’ve demonstrated how to configure Caddy with an external SSL/TLS certificate from a commercial Certificate Authority. Using Ansible, we’ve automated copying the certificate files, concatenating the full chain, and configuring Caddy to use the certificate for encrypted communication. By following this guide, you can ensure that your Caddy server is securely configured with external certificates, making it ready for production with minimal manual intervention.

By automating this process, you can easily scale and maintain secure configurations for multiple servers, saving you time and reducing the chance of errors.

Irene Ufia is a software engineer specializing in DevSecOps (Blockchain Infrastructure).

Follow me for insights and technical tips: LinkedIn | Github

DevSecOps — Community 🚀

Thank you for being a part of the DevSecOps — Community community! Before you go:

• Be sure to clap and follow ️ the Author👏️️
• Follow: Newsletter | LinkedIn Groups |
• More content at DevSecOps — Community

How to Configure Caddy with an External SSL Certificate Using Ansible was originally published in devsecops-community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you noticed how finance isn’t just about banks and money anymore? Remember when banking was limited to banks?

Well, those days are long gone. We’re witnessing a remarkable shift where financial services are seamlessly woven into our everyday apps and platforms—an era of embedded finance.

This transformative concept involves integrating financial services within other industries, allowing businesses to offer financial products and services as part of their core offerings. The integration is seamless, offering customers a streamlined and more convenient experience.
Most of us have probably used embedded finance without necessarily knowing it. For example, companies like Uber and Lyft allow users to seamlessly pay for rides through the app; they provide payment processing within their platforms, integrating financial transactions with their core service.

At its essence, embedded finance empowers industries like retail, e-commerce, and even gaming to provide tailored financial services such as payments, lending, insurance, and investments, leveraging the underlying infrastructure of established financial institutions.

Impact of Blockchain on Embedded Finance

Blockchain, with its decentralized and immutable ledger system, offers a secure and transparent environment for financial transactions. This technology has become a revolutionary innovation that’s amplifying the potential of embedded finance. Its adoption and impact on embedded finance are significant, primarily through enhanced security and tokenization.

Tokenization, a pivotal aspect of blockchain, involves the conversion of real-world assets or rights into digital tokens. These tokens can represent anything of value — from currencies and stocks to real estate and even art.

By tokenizing assets, their ownership can be divided, traded, and transferred swiftly and securely on a blockchain network, opening new avenues for liquidity and accessibility previously unimaginable in traditional finance.

Advantages of Blockchain and Tokenization in Embedded Finance

1. Accelerated Settlements: Using blockchain technology, transactions can be settled more quickly and accurately.
2. Enhanced Security: Blockchain’s cryptographic principles ensure tamper-proof transactions, reducing the risks of fraud and enhancing security and trust in financial dealings.
3. Increased Efficiency: Smart contracts and automated self-executing contracts on the blockchain enable the automatic execution of predefined actions when specific conditions are met, streamlining processes and reducing administrative overhead.
4. Improved Accessibility: Tokenization facilitates fractional ownership, enabling broader access to high-value assets that were previously out of reach for many individuals.

Influence of Blockchain on Embedded Finance

Real-world Applications:

Blockchain-powered embedded finance has made substantial strides across industries. Digital wallets are one of the most prominent examples of embedded banking.
PayPal’s acceptance of Bitcoin as a form of payment is a prime example of the convergence of DeFi and embedded finance in the traditional economy.

Platforms like RealT and Propy have innovated real estate by utilizing blockchain for property tokenization, contributing to the projected annual growth rate (CAGR 2024–2028) of 3.41%, resulting in a market volume of US$729.40 trillion by 2028, as reported by Statista.

This breakthrough allows properties to be digitally divided, offering fractional ownership, liquidity, and increased investor accessibility.

Expanding beyond real estate, blockchain’s transformative impact continues to reshape financial landscapes. Leveraging blockchain’s capabilities, key players like Interstellar have revolutionized cross-border payments within Africa by providing the underlying blockchain infrastructure that facilitates direct transactions using local currencies, promoting financial inclusion and efficiency.

In the dynamic Nigerian blockchain ecosystem, Convexity’s introduction of the cNGN initiative stands out.
The cNGN stablecoin, anchored to the Nigerian naira, aims to fortify financial stability and enable seamless digital transactions within the economy.
The recent adoption of stablecoin initiatives by the Central Bank of Nigeria underscores the nation’s commitment to embracing blockchain for enhancing financial accessibility and stability.

Global Trends:

Across different regions, blockchain’s impact on embedded finance varies but presents transformative potential. In Southeast Asia, blockchain-based remittance services, like those offered by companies such as InstaReM, have gained momentum. Reports by Juniper Research suggest that blockchain-based remittance solutions have the potential to reduce costs by 50% compared to traditional methods.

In Africa, initiatives such as Sytemap by HouseAfrica have leveraged blockchain for transparent and secure land registries, ensuring immutable records of property ownership and thereby addressing challenges related to land disputes.

Regulatory Adaptation:

Global regulatory frameworks are evolving to embrace blockchain-based finance. In Africa, progressive steps are being taken to accommodate this transformative technology.

For instance, Nigeria’s Securities and Exchange Commission (SEC) has implemented a regulatory framework for digital assets, categorizing cryptocurrencies as securities and ensuring investor protection and market integrity. South Africa’s Financial Sector Conduct Authority (FSCA) has released guidelines outlining the regulatory framework for crypto assets and service providers, promoting responsible innovation and consumer protection.
Countries like Kenya and Ghana are actively exploring regulatory frameworks to harness the potential of blockchain technology in various sectors. Kenya’s Capital Markets Authority (CMA) has expressed interest in blockchain’s potential for capital markets, while Ghana’s central bank has initiated discussions on a digital currency pilot project. These initiatives reflect Africa’s growing interest in fostering a conducive regulatory environment for blockchain-based innovations.

Collaborative efforts within the African continent, such as the African Union’s African Blockchain and Digital Assets Framework, aim to facilitate discussions on regulatory standards and frameworks, promoting uniformity and fostering innovation across the region’s blockchain landscape.

User-centric Adoption:

Initiatives focused on user experience and education are driving blockchain adoption. Mobile applications like Coinsher, MetaMask and Trust Wallet offer simplified access to blockchain-based financial services.
Educational workshops and initiatives like ConsenSys Academy and Binance Academy are empowering users with the knowledge needed to navigate and utilize blockchain technologies effectively. Data from Statista indicates a rising trend in the number of blockchain wallet users globally, demonstrating increasing user engagement.

Bottom Line and Way Forward

The rise of embedded finance, empowered by blockchain technology, heralds a new era of seamless financial integration across diverse industries. Blockchain’s role in enabling tokenization, enhancing security, and fostering innovation has revolutionized financial services.

As financial services intertwine with everyday apps, protecting sensitive user data and ensuring compliance with stringent data privacy regulations like GDPR is paramount to ensure sustainable growth. Innovative technologies like zero-knowledge proofs are emerging as shields against data breaches, allowing secure verification without compromising confidentiality.

By implementing robust encryption protocols and aligning with regulatory frameworks, businesses not only fortify user privacy but also avert potential legal repercussions, bolstering trust in embedded financial services.

To address blockchain’s scalability and interoperability hurdles, innovative solutions are emerging.

Reports show significant market growth for projects prioritizing interoperability, underscoring the rising importance of such solutions in the blockchain space.

Layer 2 scaling solutions like the Lightning Network with Ethereum’s consensus layer – Ethereum 2.0 upgrades aim to boost transaction speed. Bantu Blockchain also offers high throughput and low transaction costs, enhancing scalability with its efficient consensus mechanism.
Interoperability protocols such as Polkadot, Cosmos, and Bantu’s inter-chain communication facilitate seamless interaction between different blockchains.

Overall, the convergence of embedded finance and blockchain technology presents vast opportunities for financial inclusion, transparency, and efficiency, signaling a promising future for a more interconnected and accessible global financial ecosystem.

This question appears to be one of the oldest interview questions for most software engineering positions. An attempt to answer this question would lead to covering a wide range of topics such as DNS request, TCP/IP, Load-balancer, Firewall, SSL, HTTP/HTTPS, Web and Application servers and Database. What really happens behind the scene when you type https://www.google.com in your browser and press ‘Enter’? How is information transferred via the internet? Let’s take a look.

When we type the website name or address — or more technically called a URL, for example, https://www.google.com into our browser (Google, Safari, Firefox or any browser) and press Enter, the first thing the browser does is break down the URL in pieces — The URL(Uniform Resource Locator) is nothing more than the address of a given unique resource on the Web. The URL address above basically is composed of different parts as seen below:

The first part of the URL is the scheme, which indicates the protocol (a protocol is a set method for exchanging or transferring data around a computer network)that the browser must use to request the resource. Usually, for websites, the protocol is HTTPS or HTTP (its unsecured version). The separator between the scheme and authority is ://. The colon separates the scheme from the next part of the URL, while // indicates that the next part of the URL is the authority. The domain indicates which Web server is being requested.

Usually, asides from the domain name, an IP address may also be used (but this is rare as it is much less convenient because words are easily remembered by humans than numbers, like the way you save contacts on your phone, Domain Name Servers are the phonebook of the internet).

The browser checks the hostname/domain name for characters that are not in a-z, A-Z, 0-9, -, or .. Since the hostname is google.com there won’t be any, but if there were the browser would apply Punycode encoding to the hostname portion of the URL( A way of converting non-ASCII Unicode characters in the hostname).

The next step is the HSTS (HTTP Strict Transport Security) list check. The browser checks its preloaded HSTS list. This is a list of websites that have requested to be contacted via HTTPS only. If the website is on the list, the browser sends its request via HTTPS instead of HTTP. Otherwise, the initial request is sent via HTTP. (Note that a website can still use the HSTS policy without being in the HSTS list. The first HTTP request to the website by a user will receive a response requesting that the user only send HTTPS requests. However, this single HTTP request could potentially leave the user vulnerable to a downgrade attack, which is why the HSTS list is included in modern web browsers.)

The next step is the DNS Lookup and a series of queries by the DNS Resolver that we will highlight below:

Before the page and any resource on the page are loaded, the DNS must be resolved so the browser can establish a TCP connection to make the HTTP request. Since the operating system doesn’t know where “www.google.com” is, it queries a DNS resolver. (A DNS resolver, also called a recursive resolver, is a server designed to receive DNS queries from web browsers and other applications. The resolver receives a hostname — for example, www.example.com — and is responsible for tracking down the IP address for that hostname). Browser checks if the domain is in its cache (to see the DNS Cache in Chrome, go to chrome://net-internals/#dns). If not found, the browser calls gethostbyname the library function (varies by OS) to do the lookup. gethostbyname checks if the hostname can be resolved by reference in the local hosts file (whose location varies by OS) before trying to resolve the hostname through DNS. At this point, the resolver goes through a process called recursion to convert the domain name into an IP address.

DNS Resolver Iterative Query to the Root Server:

The DNS resolver starts by querying one of the root DNS servers for the IP of “www.google.com.” This query does not have the recursive flag and therefore is an “iterative query,” meaning its response must be an address, the location of an authoritative name server, or an error.

Root Server Response:

These root servers hold the locations of all of the top-level domains (TLDs) such as .com, .cm, .io, and newer generic TLDs such as .camera. The root usually doesn’t have the IP info for “www.google.com,” but it knows that .com might know, so it returns the location of the .com servers.

DNS Resolver Iterative Query to the TLD Server:

Like the Root Servers, each of the TLDs has 4–13 clustered name servers existing in many locations. In this case, we will be using the gTLD servers controlled by Verisign, who run the .com, .net, .edu, and .gov among gTLDs. In google.com, the TLD server is “com”. So, the resolver queries one of the .com name servers for the location of google.com. The request is then sent to the authoritative nameserver.

TLD Server Response:

Each TLD server holds a list of all of the authoritative name servers for each domain in the TLD. For example, each of the 13 .com gTLD servers has a list with all of the name servers for every single .com domain. The .com gTLD server does not have the IP addresses for google.com, but it knows the location of google.com’s name servers. The .com gTLD server responds with a list of all of google.com’s NS records. In this case, Google has four name servers, “ns1.google.com” to “ns4.google.com.”

DNS Resolver Iterative Query to the Google.com NS:

Finally, the DNS resolver queries one of Google’s name servers for the IP of “www.google.com.”

Google.com NS Response: This time the queried Name Server knows the IPs and responds with an A or AAAA address record (depending on the query type) for IPv4 and IPv6, respectively.

DNS Resolver Response to OS: At this point, the resolver has finished the recursion process and is able to respond to the end user’s operating system with an IP address.

Internet Protocol Suite

Finally, the browser knows where to find www.google.com and it’s now time to make a connection, to access the website requested. Browsers use internet protocols to build such connections.

Internet Protocol Suite aka TCP/IP (TCP stand for Transmission Control Protocol) is the most common protocol used for many types of HTTP requests. It’s a set of rules governing the format of data sent via the internet or local network, such as sending e-mails, streaming videos, or connecting to a website.

Traffic and Security Control

Once the TCP connection is established, it is time to begin transferring data! But not so fast, first, we need some traffic control — meet the load balancer…

A load balancer, like HAProxy, is a server that helps handle more web traffic and avoid downtime. The load balancer receives traffic from the internet and then distributes it among multiple servers so as to not overload any particular server with too many requests and example of an algorithm that we can use is the round-robin, which distributes the requests alternating between all the servers evenly and consequentially, or the least-connection, which distributes requests depending on the current server loads. Load balancers are essential for websites with a lot of traffic such as google.com! But in a day and age when online security concerns are the top priority of computer users, not anyone can gain access. Firewalls provide you with the necessary safety and protection.…

A firewall is a software or hardware device that blocks unauthorised access to or from private networks. It acts as a barrier between a secured internal network and the most vulnerable network, e.g. the internet. Firewalls are set up at every connection to the Internet, therefore subjecting all data flow to careful monitoring. Firewalls can also be tuned to follow “rules”. These Rules are simply security rules that can be set up by yourself or by the network administrators to allow traffic to their web servers, FTP servers, and Telnet servers, thereby giving the computer owners/administrators immense control over the traffic that flows in & out of their systems or networks. Rules will decide who can connect to the internet, what kind of connections can be made, and which or what kind of files can be transmitted in out. Basically, all traffic in & out can be watched and controlled thus giving the firewall installer a high level of security & protection. In the case of our example, when the browser asks for the website at the address 197.210.54.75, that request has been processed by a firewall which will decide if it’s safe, or if it’s a threat to the server’s security.

Let's talk about the Secure Socket Layer (SSL)

As opposed to unsecured HTTP URLs which begin with “http://” and use port 80 by default, secure HTTPS URLs begin with “https://” and use port 443 by default. HTTP is insecure and is subject to eavesdropping attacks which, if critical information like credit card details and account logins is transmitted and picked up, can let attackers gain access to online accounts and sensitive information. SSL is designed on top of TCP. It is a transparent protocol which requires little interaction from the end user when establishing a secure session. Ensuring data is either sent or posted through the browser using HTTPS is ensuring that such information is encrypted and secure. Behind the scenes, the browser retrieves the SSL certificate whenever it connects to a secure site. The browser checks to make sure that the certificate has not expired, whether or not the issuing authority is one that the browser trusts, and that the certificate is being used by the same website to which it was issued. If either safety check fails, the browser will let the user know that the site is not secured by SSL through a warning message. The user has the choice of trusting the site or leaving

The browser sends the HTTP request to the server

Now that the browser has a connection to the server, it follows the rules of communication for the HTTP(s) protocol. HTTP stands for HyperText Transfer Protocol and is perhaps the most popular application protocol used by the World Wide Web. It’s used by the browser and web server to communicate. It is a stateless, text-based protocol. It starts with the browser sending an HTTP request to the server to request the contents of the page. The HTTP request contains a request line, headers (or metadata about the request), and a body. The request line contains information that the server can use to determine what the client (in this case, your browser) wants to do.

An application server is a software program responsible for operating applications, communicating with the database servers, managing user information, and more. It works with web servers and is able to serve a dynamic application using the static content from the web server.

Another crucial component in the client-server computing environment is the database server, which consists of hardware and software that run a database. A database is a collection of data stored in an orderly manner and the database server is the program that interacts with the database. To run a system efficiently, you’d need an effective memory of the past and present records that went into and/or came out of that particular system. The two main ones are relational databases(e.g MySQL, Oracle, PostgreSQL) and non-relational databases(e.g MongoDB, Cassandra).

The server breaks down the request into the following parameters:

• HTTP Request Method (either GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS, or TRACE). In the case of a URL entered directly into the address bar, this will be GET.
• Domain, in this case — google.com.
• Requested path/page, in this case — / (as no specific path/page was requested, / is the default path).
• The server verifies that there is a Virtual Host configured on the server that corresponds with google.com.
• The server verifies that google.com can accept GET requests.
• The server verifies that the client is allowed to use this method (by IP, authentication, etc.).
• If the server has a rewrite module installed (like mod_rewrite for Apache or URL Rewrite for IIS), it tries to match the request against one of the configured rules. If a matching rule is found, the server uses that rule to rewrite the request.
• The server goes to pull the content that corresponds with the request, in our case, it will fall back to the index file, as “/” is the main file (some cases can override this, but this is the most common method).

It is important to note that the above actions happen in very few seconds in quick succession as the snap of a finger.

We covered the relationship between websites, servers, and IP addresses and stepped through each of the steps that your browser goes through when you type a URL into your browser and press enter.

For review, here are those six steps:

1. You type a URL in your browser and press Enter
2. The browser looks up the IP address for the domain
3. The browser initiates a TCP connection with the server
4. The browser sends the HTTP request to the server
5. The server processes the request and sends back a response
6. The browser renders the content mostly HTML