DEV Community: Ladipo Samuel

My Turbin3 experience: What to Expect and How to Make the Most of It

Ladipo Samuel — Fri, 23 Oct 2026 16:08:25 +0000

If you're reading this, firstly, welcome to my little talk about my experience at Turbin3! And if you've just joined the cohort, congratulations! I'm rooting for you to make it all the way to graduation.💜

The Classes and Instructors

First off, I genuinely enjoyed the classes.

Whenever Shrinath, Prince, or Glacier started teaching, you knew you were about to learn something. Sometimes you'd get lost halfway through an explanation 😂, but they're really good at breaking things down, and you can always ask questions.

Then there were the office hours with the instructors and Meowy helped a lot, where you could revisit things you didn't fully understand, ask questions, and get insights with assignments.

Big shoutout to Nate for his insights, Andreia for constantly checking up on us (her messages definitely kept my inbox busy 😂), and Varma too!

At this point, you've probably met almost all the instructors through this article. And one thing I appreciated was how approachable everyone was. You didn't have to understand everything immediately. You just had to be willing to learn and ask.

What We Actually Learned

Now, the technical side!

We started by understanding how Solana works beyond simply sending transactions. We explored wallets, keypairs, transactions, accounts, and how data and programs actually live on-chain. Then we got into SPL tokens: creating token mints, working with Associated Token Accounts (ATAs), minting and transferring tokens, and creating NFTs with metadata.

As we progressed, we worked with Rust and Anchor to understand how Solana programs are structured, how instructions interact with accounts, and how concepts like PDAs, account constraints, and signing fit into the bigger picture. And eventually, all that learning leads to the capstone, where you get to apply these concepts to something you're building yourself.

My advice? Prepare a little before classes, interact, and ask questions. Even if your question sounds basic, ask it. Someone else might be wondering the same thing.

The Assignments (Yes, Those Assignments!!!!)

I have to talk about these because, mehn, they can be a lot sometimes! But please, take them seriously.

It's tempting to throw an assignment straight into AI and collect the solution, especially when you're stuck. But try to understand what you're building first. Read the code, experiment, break things, message your colleagues, debug, and figure out why something works.

AI can help you learn faster, but don't let it do all the thinking for you. Those assignments gradually build your problem-solving skills, and by the time you get to your capstone, you'll be glad you took them seriously. Some days will be overwhelming, but you're learning skills you'll actually need when building outside the cohort.

WE'RE WAITING AND ROOTING FOR YOUUU!

The People You'll Meet

This might genuinely be one of my favourite parts of the entire experience. I met some amazing people like Light, Nisarg, Hailey, Xelabyte, Sohum, and many others.

Imagine being in Nigeria, wrapping up your day, while someone in another country is just getting started. Different time zones, backgrounds, experiences, and perspectives, but everyone is learning and building together.

You get to hear how other people think, approach problems, and see opportunities you might never have considered. So please, don't just attend classes and disappear. Make friends, Talk to people, Collaborate, Ask what they're building. You never know where those connections might lead.

And yes, your instructors can be your friends too! They're approachable and genuinely willing to help. Just be polite, respectful, and don't be afraid to reach out.

Enrichment Week: Getting Closer to the Industry

Then comes enrichment week!

I like to think of this as the week where you get to connect with people already doing amazing things in the ecosystem. We had opportunities to learn from people connected to places like Superteam, the Solana Foundation, and other Web3 companies.

You get to hear different perspectives on the industry, understand career opportunities, ask questions, and learn how people actually navigate the ecosystem. One piece of advice that stayed with me was to think about who needs what you're building before you start building it.

It's easy to get excited about an idea, but does it solve a problem people actually have? Is there an audience for it? That's just one of the many things I took away. Make sure you ask your own questions and collect your own lessons too, haha.

Also, contribute whenever you can. Share your thoughts, participate in conversations, and don't assume your perspective doesn't matter.

A Few Final Things

Make good use of the Discord server!

Seriously, don't underestimate it. Ask questions, join conversations, share your progress, help someone who's stuck, and make friends. You don't have to be the smartest person in the room. Be curious, consistent, respectful, and willing to contribute.

I've summarised quite a bit here, but there's so much more you'll experience yourself, from the technical challenges to the random conversations and the excitement of finally getting something to work.

And when it's time for your capstone, try to build something you're genuinely interested in, preferably something people actually need. That makes the entire experience even more rewarding.

If you ever need advice or want to ask about my experience, feel free to DM me on X: ladicodez. But remember, your instructors are also there to help you, so make good use of that access.

I'm Ladipo Samuel, a former Software Engineering Intern at Microsoft, 12x hackathon winner, DevRel Engineer, and now a proud Turbin3 graduate!

Wishing you the very best throughout your journey.

Good luck, and happy building! 💜

really good read

Ladipo Samuel — Mon, 05 Oct 2026 18:36:05 +0000

Ladipo Samuel

Oct 5

Building an SPL Token on Solana: Minting Tokens and Understanding ATAs

#devrel #solana

3 min read

Building an SPL Token on Solana: Minting Tokens and Understanding ATAs

Ladipo Samuel — Mon, 05 Oct 2026 18:15:08 +0000

So far, our token has a Mint and metadata, but technically, nobody owns any of it yet. We haven't minted a single token, which means the supply is still zero.
The next step seems obvious: mint some tokens. But while doing this, I ran into another question that helped me understand Solana better: when tokens are minted, where exactly do they go?
Your tokens don't actually sit in your wallet
At first, it's easy to think of a wallet as one account containing everything you own. On Solana, SPL tokens work a little differently. Your wallet controls them, but the balances themselves live in separate Token Accounts.

If I own three different tokens, I can picture it like this:

My Wallet
│
├── Token Account for Token A → 50
├── Token Account for Token B → 100
└── Token Account for Token C → 20

Each Token Account is for one specific Mint. This means the account holding my balance of Token A isn't the same account holding my balance of Token B.
This is where Associated Token Accounts, or ATAs, come in.

Understanding the ATA
An ATA is the standard Token Account for a specific wallet and Mint combination.
I find it easier to think of it as answering this question:

Where should this wallet's balance of this particular token live?

Given the wallet and Mint, we can deterministically derive its ATA, meaning the same wallet and Mint will always lead us to the same ATA address.

Wallet + Mint
     ↓
    ATA
     ↓
Balance of that token

So my wallet can have one ATA for the token we're building, while another wallet will have a different ATA for the exact same token.
In the code, we derive ours like this:

const [ata] = await findAssociatedTokenPda({ mint, owner: signer.address, tokenProgram: TOKEN_PROGRAM_ADDRESS, });

Something from the architecture article shows up again here: finding an address doesn't necessarily mean an account exists there yet. We know where our ATA should be, but if it hasn't been created on-chain, we still need to create it.
Once that account exists, we finally have somewhere to send our tokens.

Now we can actually mint

Minting means creating new units of our token and sending them to a Token Account.
So underneath the SDK functions, what we're really asking the Token Program to do is:

Our Mint
   │
   │ create new token units
   ▼
Our ATA

But we can't just mint tokens whenever we want. When we initialized the Mint earlier, we assigned a mint authority. That authority is what gives our wallet permission to create new units of the token. Knowing the Mint address alone isn't enough to increase its supply.
Decimals matter here too. Our Mint uses 6 decimals, so:

1 token = 1,000,000 base units
100 tokens = 100,000,000 base units

What actually changed?
This is probably the simplest way to see what minting did. Once the ATA has been created, but before minting:

Mint Account
Supply: 0

ATA
Balance: 0

We mint 100 tokens into our ATA:

Mint Account
Supply: 100
      │
      │ mint
      ▼
ATA
Balance: 100

Two pieces of state changed. The Mint's total supply increased because 100 new tokens now exist, and our ATA's balance increased because that's where those tokens were sent.
That distinction ties everything together for me where the Mint keeps track of the token itself and its overall supply, while Token Accounts keep track of who holds how much.

Where we are now
We've gradually moved from defining a token to actually having tokens that can be used:

Create Mint
     ↓
Add Metadata
     ↓
Derive/Create ATA
     ↓
Mint Tokens
     ↓
Our ATA now holds them

At this point, we finally have actual token units sitting in an account controlled by our wallet.
But tokens become more interesting when they can move. So the next question is: if I want to send some of these tokens to another wallet, what exactly happens to my ATA, their ATA and the Mint's total supply?
That's where we'll pick up with SPL token transfers.

Building an SPL Token on Solana: Adding Metadata

Ladipo Samuel — Sat, 03 Oct 2026 17:08:59 +0000

In the previous part, we created and initialized an SPL Token Mint on Solana Devnet. At that point, the Mint existed on-chain with its decimals and authorities configured, but we hadn't really given it an identity yet.
That brings us to metadata. When we see a token with a name, symbol and other descriptive information, where does that information come from? Before jumping into the code, I wanted to understand where all of that information actually lives.

The Mint and its metadata are not the same thing
One thing that helped me understand this was separating the Mint Account from the metadata attached to it. The Mint Account handles the token itself. It stores information such as the token’s decimals, supply, mint authority and freeze authority. It does not directly store things like the token’s name, symbol or image.
That information lives separately as metadata. In our case, we use the Metaplex Token Metadata program, a Solana program for creating and managing metadata for tokens and NFTs. So instead of adding a name or symbol directly to the Mint Account, we create another account that holds this information and connects it back to the Mint.
I like to picture it this way:

Mint Account
├── Supply
├── Decimals
├── Mint Authority
└── Freeze Authority

        ↓ associated with

Metadata Account
├── Name
├── Symbol
└── URI

The Mint is still the identity of the token on Solana. The metadata simply gives applications and people more useful information about what that token represents.
This also explains why we needed the Mint address from the previous part. When creating the metadata, we have to tell the metadata program exactly which Mint this information belongs to.

What does the URI actually point to?
The metadata account can store information like the token's name and symbol, but we don't want to put every piece of information directly on-chain. Things like an image, description, or other details can be stored elsewhere and referenced through a URI.
Think of the URI as a link pointing to another metadata file that contains more information about the token. That file can look something like:

{
  "name": "My Token",
  "symbol": "MTK",
  "description": "A token created while learning SPL tokens",
  "image": "https://..."
}

Adding the metadata

With that in mind, the code started making a lot more sense to me. We already have the Mint address from the previous part, so the first thing we do is reference that same Mint and load our wallet as the signer.

const mint = publicKey("YOUR_MINT_ADDRESS");

const umi = createUmi("https://api.devnet.solana.com");
const keypair = umi.eddsa.createKeypairFromSecretKey(
  new Uint8Array(wallet)
);
const signer = createSignerFromKeypair(umi, keypair);

umi.use(signerIdentity(signer));

Here, Umi is the toolkit we're using to interact with Metaplex. We connect it to Devnet, reconstruct our signer from the wallet we already have, and tell Umi to use that signer for the operations we're about to perform.
We then define which Mint the metadata belongs to and provide the information we want associated with it: things like the token's name, symbol and URI. The important part for me was understanding what we were asking the program to do: create metadata for this specific Mint, with its mint authority authorizing the operation.

What actually changed?
After the transaction is sent and confirmed, we haven't created any new tokens. Our Mint still represents the same token, and this operation doesn't suddenly increase its supply.
What we've done is associate a metadata account with it:

Mint
│
├── decimals
├── supply
└── authorities
        │
        └── associated Metadata
              ├── name
              ├── symbol
              └── URI

We aren't modifying the Mint to squeeze a name, image and description into it. The Mint and its metadata have different responsibilities, but they are connected.

Where we are now

So far, we've created the Mint and added metadata to give it a recognizable identity. But there is still one important thing missing: we haven't actually minted any token units yet. Which leaves us with the next question: when we mint tokens, where do they actually go?
That takes us into Token Accounts and Associated Token Accounts (ATAs), which is what we'll look at next.

Building an SPL Token: Creating the Mint

Ladipo Samuel — Sat, 05 Sep 2026 15:30:18 +0000

Now that we have a mental model of how Solana works, it’s time to actually use it.

We’ve talked about accounts holding state, programs containing the logic, instructions telling those programs what to do, and transactions bringing those instructions together. Creating an SPL Token Mint is a good place to see all of those concepts working together.

In this part, we’ll create and initialize an SPL Token Mint on Solana Devnet, but more importantly, we’ll break down what is actually happening underneath the code.

So, what exactly is a Mint?

If I tell Solana to give someone 100 of a particular token, Solana first needs to know what that token is. What defines it? How divisible is it? How many units currently exist? Who has the authority to create more? That is where the Mint Account comes in.

A Mint Account represents a particular type of token on Solana. It stores information about that token such as its current supply, decimals, mint authority and optional freeze authority. It does not store how many tokens I personally own. That belongs somewhere else, which we’ll get to when we talk about Token Accounts and ATAs.

A simple way to separate the two is this: the Mint tells us what token exists, while a Token Account tells us how much of that token a particular owner holds. Before looking at any code, the complete process for creating our Mint looks like this:

Connect to Solana Devnet
Load our wallet
Generate a new keypair for the Mint
Calculate how much space a Mint Account needs
Calculate the lamports required for the account
Ask the System Program to create the account
Ask the Token Program to initialize it as a Mint
Put both instructions inside a transaction
Sign the transaction
Send and confirm it on Solana

There are quite a few SDK functions involved when implementing this, but underneath all that syntax, this is really what the entire spl_init.ts file is doing.

Starting with the wallet and Mint address
We first load our wallet and turn it into a signer. The wallet is important because someone has to pay the transaction fee and authorize the operations that require a signature.

const signer = await createKeyPairSignerFromBytes(
  new Uint8Array(wallet)
);

The exact SDK function isn't the important part here. What matters is that we now have a signer that represents our wallet and can be used when constructing the transaction.
Next, we generate a new keypair for the Mint.

const mint = await generateKeyPairSigner();

There is an important distinction here. Generating this keypair does not create anything on Solana. At this point, we simply have a new keypair locally and a public address that we intend to use for our Mint. Solana does not have an account at that address yet. We still have to create one.

Creating the account before creating the Mint
This is where Solana's account model becomes important. Programs contain the logic, while accounts hold state. Since a Mint needs to store information like supply, decimals and authorities, that information needs somewhere to live.

Before creating the account, we calculate how much storage a Mint requires and how many lamports are needed for an account of that size.

const mintSpace = getMintSize();
const rent = await rpc
  .getMinimumBalanceForRentExemption(BigInt(mintSpace))
  .send();

Now we know the amount of space to allocate and how much to fund the account with.
The next instruction asks the System Program to create the account.

const createAccountIx = getCreateAccountInstruction({
payer: signer,
newAccount: mint,
lamports: rent,
space: mintSpace,
programAddress: TOKEN_PROGRAM_ADDRESS,
});

Reading this without focusing too much on the syntax makes it fairly straightforward. Our wallet is paying, mint is the new account we want to create, lamports funds it, space determines how much storage it gets, and TOKEN_PROGRAM_ADDRESS says that the Token Program will own the account.
That last part is important because on Solana, an account's owner is a program, not necessarily the person we might casually describe as owning something. The owner program is the program allowed to modify that account's data according to its rules.

At this stage, however, we have only described how the account should be created. We still haven't told the Token Program that this account should behave as a Mint.

Turning the account into a Mint

This is where the second instruction comes in.

const initializeMintIx = getInitializeMintInstruction({
  mint: mint.address,
  decimals: 6,
  mintAuthority: signer.address,
  freezeAuthority: signer.address,
});

The first instruction says, “create this account.” The second says, “initialize this account as a Mint.”

This is also where we configure some of the Mint's properties. With decimals: 6, one whole token can be represented as 1,000,000 base units. We also set our wallet as the mintAuthority, which gives it the authority to create new units of this token.

One distinction worth understanding here is Token Program ownership versus mint authority. The Token Program owns the Mint Account and enforces the rules around how its data can change. Our wallet being the mint authority simply means it has permission, under those rules, to authorize the creation of new token units. They are two completely different responsibilities.

Instructions are not transactions

Another useful distinction is that creating these instruction objects has still not changed anything on-chain.
An instruction is essentially a description of an operation we want a Solana program to perform. At this point, we have prepared two of them: one for the System Program to create the account and another for the Token Program to initialize it.
We then put both into a transaction, and their order matters. The System Program has to create the account before the Token Program can initialize it as a Mint.

Conceptually, the transaction looks like this:
Transaction

  Instruction 1
  System Program → Create Account

  Instruction 2
  Token Program → Initialize Mint

The transaction also needs a fee payer and a recent blockhash. The fee payer is the account paying the network fee, while the recent blockhash gives the transaction a validity window and helps prevent old transactions from being replayed indefinitely.
Once everything is assembled, the required signers sign the transaction. Signing is essentially authorization. It proves that the required keys approved the transaction.

Only after we send that signed transaction to Solana does the work we've been preparing actually happen on-chain.
The System Program creates the account first, then the Token Program initializes it as a Mint. Once the transaction is confirmed, we get our Mint address and transaction signature. The Mint address identifies our newly created token Mint, while the transaction signature identifies the transaction and can be used to inspect what happened on-chain.

Have we created any tokens yet?

No, and this is probably the most important distinction in the entire process.

Creating a Mint is not the same thing as minting tokens.
At this point, we have defined a token on Solana. It has an address, decimals and authorities, but its supply is still zero. We haven't created any actual token units or given them to anyone yet.
The way I like to think about the state we're currently in is:
Mint Account
What token exists? → Done

Token Supply
How many tokens have been created? → 0

Token Account
Who holds how many tokens? → Not created yet
So if I had to explain the whole spl_init.ts file in one sentence, it would be this:

We generated an address for our Mint, asked the System Program to create an account there, asked the Token Program to initialize that account as a Mint, then packaged those instructions into a transaction, signed it and sent it to Solana.
We now have the foundation for our token, but an address alone isn't very descriptive. We still need a way to associate information like a name, symbol and URI with it.
That is what we will treat next with metadata.

Building on Solana with Turbin3: Understanding the Architecture First

Ladipo Samuel — Fri, 04 Sep 2026 17:37:56 +0000

I recently started building with Turbin3, and before getting deeper into SPL tokens, NFTs and Anchor, I wanted to properly understand what is actually happening underneath the code.

I’ve worked with other ecosystems before, including Sui and Cardano, and one thing I’ve noticed is that every blockchain has its own way of structuring things. With Solana, concepts like accounts, programs, instructions, transactions, PDAs and CPI come up almost everywhere. Once I started seeing how they connect instead of learning each one separately, the architecture became much easier to understand.

So before getting into tokens and writing more code, I wanted to start with the mental model I currently use for Solana.

The simplest way I understand Solana

When I perform an action on Solana, I picture the flow like this:

Wallet
   ↓
Transaction
   ↓
Instruction(s)
   ↓
Program
   ↓
Accounts
   ↓
State changes

My wallet signs a transaction. That transaction contains one or more instructions, and each instruction tells a particular program what action I want it to perform and which accounts are involved. The program processes that instruction, and if everything is valid, the relevant accounts are updated.

That simple flow helped me connect most of the concepts I was learning.

Programs contain logic, accounts contain state

This was one of the first distinctions that made Solana easier for me to reason about.

A program contains the logic and rules for what can happen, while accounts are where data or state lives.

For example, imagine I’m building an escrow. The program could contain the rules for depositing, releasing and refunding funds, while an account could store information such as the sender, receiver, amount and current status of that escrow.

Coming from backend development, I loosely think about it like this:

Program ≈ backend logic
Account ≈ stored state/data

It’s not a perfect comparison, but it gives me a useful starting point.

Another thing that initially needed some clarification was account ownership. When we say an account is owned by a program, we are not talking about the person who controls a wallet. The owner is the program that has authority to modify that account’s data according to Solana’s rules.

Instructions tell programs what to do

Once programs and accounts make sense, instructions become much easier to understand.

An instruction is basically a request for a specific program to perform an action. For example:

System Program → Create an account
Token Program  → Mint tokens
Token Program  → Transfer tokens

An instruction needs to identify the program being called, the accounts involved, and the data describing what should happen.

So I think about an instruction as:

Program  → Who should execute this?
Accounts → What accounts are involved?
Data     → What should the program do?

The accounts passed into an instruction can also have different roles. A signer means authorization from that account is required, while a writable account is one whose state may be changed by the instruction.

Transactions bring instructions together

An instruction describes an action, but a transaction is what packages one or more of those actions together and sends them to Solana.

For example, when we create an SPL Token Mint later, one transaction can contain:

Transaction
   │
   ├── Instruction 1
   │      System Program → Create Account
   │
   └── Instruction 2
          Token Program → Initialize Mint

This is something I found useful to understand early: creating the account and initializing it as a Mint are actually two different operations, even though we can put both instructions inside the same transaction.

The transaction also contains things like the required signatures, a fee payer and a recent blockhash. The fee payer pays for the transaction, while the recent blockhash helps keep the transaction fresh and prevents old transactions from being reused indefinitely.

Once the required signatures are there, the transaction is sent to the network, validators process its instructions, and the state of the relevant accounts can change.

Where do PDAs fit into this?

PDAs, or Program Derived Addresses, sounded more complicated to me at first than they actually turned out to be.

A PDA is an address derived from:

Program ID + Seeds + Bump → PDA

Unlike a normal wallet address, a PDA has no private key. It is derived to be off the Ed25519 curve, so there isn’t a normal keypair sitting somewhere that can sign for it.

Instead, the Solana runtime allows the program associated with that PDA to act with its authority when the correct seeds and bump are provided.

This makes PDAs useful for things like program state, vaults and escrows.

For example, an escrow program could derive an address using:

"escrow" + user wallet + escrow id

Because the derivation is deterministic, the same inputs will always lead to the same PDA.

The bump is an extra byte used during this process to find a valid off-curve PDA.

One distinction I also found important is that deriving a PDA does not create an account. Derivation only gives us an address. If we want an actual account there to hold data or lamports, that account still needs to be created.

CPI is how programs work with other programs

The last piece of this mental model is CPI, or Cross Program Invocation.

CPI simply means one Solana program calling another program.

Suppose I build an escrow program that needs to transfer tokens. My program doesn’t need to implement the Token Program’s functionality itself. It can invoke the Token Program:

Escrow Program
      ↓ CPI
Token Program
      ↓
Transfer tokens

That ability for programs to invoke other programs is a big part of how programs compose on Solana.

PDAs also become useful here. If a PDA needs to act as an authority during a CPI, the program can provide the PDA’s seeds and bump, allowing the runtime to verify that the PDA was derived by that program.

How I approach Solana code now

One thing I’m trying to avoid while learning Solana is memorizing SDK functions without understanding why I’m calling them.

Instead, when I see a piece of Solana code, I first try to figure out:

What program am I calling?
What accounts does it need?
Which accounts need to sign?
Which accounts can change?
What instruction am I asking the program to perform?
Is another program being called through CPI?
Is there a PDA involved?

Once I can answer those questions, the SDK functions start to feel more like tools for expressing something I already understand rather than random functions I need to memorize.

So the mental model I’m taking forward is still:

Wallet
   ↓
Transaction
   ↓
Instruction(s)
   ↓
Program
   ↓
Accounts
   ↓
State changes

With two important additions:

Program A → CPI → Program B

Program ID + Seeds + Bump → PDA

That’s the foundation I wanted to get right before moving deeper into SPL tokens and NFTs.

In the next part, we’ll put this architecture into practice by creating an SPL Token Mint on Solana Devnet. That’s where we’ll see the System Program, Token Program, accounts, instructions, signers and transactions actually come together in code.

dockerizing your fastapi application

Ladipo Samuel — Thu, 16 Jul 2026 09:30:20 +0000

Ladipo Samuel

Jul 16

Docker Series Part 3: Dockerizing Your First Application.

#beginners #docker #python #tutorial

5 min read

Docker Series Part 3: Dockerizing Your First Application.

Ladipo Samuel — Thu, 16 Jul 2026 09:30:02 +0000

In the first two parts of this series, we focused on understanding Docker.

We talked about why Docker was created, why the infamous "works on my machine" problem existed for years, and how Docker solved it. We also looked behind the scenes at Docker's architecture and understood the relationship between the Docker Client, Docker Engine, Docker Hub, Images, and Containers.

Now it's time to put all of that knowledge into practice.

Today, we'll take a simple FastAPI project and package it into a Docker Image that can run consistently across different environments. The project itself is intentionally small because the goal isn't to learn FastAPI: it's to understand how Docker packages applications.

I'll also attach the GitHub repository used in this article so you can clone it and follow along.

github link: https://github.com/ladicodes/docker-demo

Our Project

Before introducing Docker, our project looks like this:

docker-workshop-api/
│
├── main.py
├── requirements.txt
└── README.md

At this stage, it's just another Python application.

It works because our machine already has Python installed, along with every dependency the project requires.

But if we send this same project to another developer, they may run into completely different problems:

Different Python versions
Missing dependencies
Different operating systems
Different environment configurations

This is exactly the kind of inconsistency Docker was designed to eliminate. Instead of sending just our source code, Docker allows us to package the entire runtime environment alongside the application.

The Dockerfile: Docker's Instruction Manual
Docker doesn't magically understand how to package your application. You have to tell it exactly what to do: that's where the Dockerfile comes in.

A Dockerfile is simply a text file containing step-by-step instructions Docker follows to build an Image.

Let's build ours one instruction at a time.

Step 1: Choosing a Base Image
FROM python:3.12-slim

Every Docker Image starts from another Image. Instead of installing Python ourselves, we're using the official Python Image published on Docker Hub.
You'll also notice we're using python:3.12-slim instead of the regular Python Image.

The slim variant removes unnecessary packages while keeping everything needed to run Python applications. This produces smaller Images, which means faster downloads, quicker deployments, and lower storage usage. We'll go much deeper into Image optimization in Part 4.

Step 2: Setting the Working Directory
WORKDIR /app

Think of this as running:

cd /app

inside the container.

From this point onward, every instruction in the Dockerfile executes relative to this directory. Having a dedicated working directory keeps the Image organized and prevents files from being scattered throughout the filesystem.

Step 3: Copying Dependencies First
COPY requirements.txt .

This line copies only the dependency file into the Image. You might be wondering: Why not copy everything immediately?
The answer is Docker Layers. Docker builds Images layer by layer.

If your dependencies rarely change but your application code changes frequently, Docker can reuse the dependency layer during future builds instead of reinstalling everything from scratch. That dramatically speeds up build times. It's a small decision now that saves minutes later in larger projects.

Step 4: Installing Dependencies
RUN pip install --no-cache-dir -r requirements.txt

The RUN instruction executes commands while the Image is being built. Here, Docker installs every package listed in requirements.txt.

The --no-cache-dir flag tells pip not to keep unnecessary installation cache files, helping reduce the final Image size. Every instruction like this becomes part of the final Image.

Step 5: Copying the Application
COPY . .

Now that our dependencies are installed, we copy the rest of the project into the Image. At this point, Docker has everything it needs:

Application code
Dependencies
Configuration
Runtime environment

The application has officially been packaged.

Step 6: Documenting the Application Port
EXPOSE 8000

This tells anyone using the Image that the application is expected to listen on port 8000. It's worth noting that EXPOSE doesn't automatically make the application accessible from your computer. It simply documents which port the application uses inside the container.

We'll map that port when we actually run the container.

Step 7: Starting the Application
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

This instruction defines what should happen whenever a container starts from this Image. In our case, Docker launches the FastAPI application using Uvicorn.

You may notice the application listens on:

0.0.0.0
This often confuses beginners. 0.0.0.0 isn't the address you'll open in your browser. Instead, it tells the application to listen on all available network interfaces inside the container.

From your own computer, you'll access the application through:

http://localhost:8000, by entering uvicorn main:app --reload

because Docker maps your computer's port to the container's port.

Building Our First Docker Image

Now that our Dockerfile is complete, it's time to package the application.

Run:

docker build -t docker-workshop-api .

Let's quickly break this command down.

docker build: Builds a Docker Image.

-t: Assigns a name (tag) to the Image.

docker-workshop-api: The name we'll use whenever we want to create containers from this Image.

dot(.): Perhaps the most overlooked part of the command. The dot tells Docker to use the current folder as the build context, allowing it to locate the Dockerfile and every file referenced by COPY.
Once the build completes, you can confirm the Image exists by running: docker images

You'll now see your newly created Image listed locally. At this point, nothing is running yet. You've simply created the package.

Creating a Running Container

Now we can create a running application from that Image.

docker run -p 8000:8000 docker-workshop-api

This is where many beginners accidentally mix up Images and Containers.

Remember:

An Image is the package. A Container is the running instance of that package.

The docker run command creates a brand-new Container from the Image before starting the application.

The -p 8000:8000 flag maps:

Your Computer (8000)
│
▼
Container (8000)

This allows your browser to communicate with the application running inside Docker.

If everything goes well, you'll see something similar to:

INFO: Uvicorn running on http://0.0.0.0:8000

Although the application listens on 0.0.0.0 inside the container, you should open:

http://localhost:8000/docs

From there, FastAPI's interactive documentation lets you test every endpoint and confirm your application is running successfully inside Docker.

Where We Go From Here

Congratulations.

You've just Dockerized your first application.

More importantly, you've connected the concepts we've covered throughout this series:

Python Project
│
▼
Dockerfile
│
▼
docker build
│
▼
Docker Image
│
docker run
│
▼
Docker Container
│
▼
Running Application

Understanding this flow is far more valuable than memorizing commands because every Docker project, whether it's a personal project or a production system follows this same journey.

But we're not done yet. Our application works, but there are still important questions to answer.

Why are some Docker Images over 1GB, while others are only a few hundred megabytes?

Why do some projects rebuild in 5 seconds, while others take 5 minutes?
How do production teams build Images that are smaller, faster, and more secure?

That's exactly what we'll explore in Part 4, where we'll dive into Docker layers, caching, .dockerignore, base Images, and practical techniques for optimizing Docker Images like experienced engineers.

See you in the next part.🚀

part 2 on understanding docker

Ladipo Samuel — Mon, 06 Jul 2026 17:53:03 +0000

Ladipo Samuel

Jul 6

Docker Explained (Part 2): Understanding Docker's Architecture, Images & Containers

#architecture #beginners #docker #tutorial

4 min read

Docker Explained (Part 2): Understanding Docker's Architecture, Images & Containers

Ladipo Samuel — Mon, 06 Jul 2026 17:29:51 +0000

One of the biggest mistakes people make when learning Docker is jumping straight into commands without understanding what's happening behind the scenes.
You'll see people type commands like:
docker run nginx

The application starts, everyone is happy, and they move on. But have you ever stopped to ask yourself: what actually happens after I press Enter?
It might seem like Docker is magically running your application, but it's actually following a simple process every single time.

Think of it like this:
You
│
▼
Docker Client
│
▼
Docker Engine
│
▼
Docker Hub (if needed)
│
▼
Docker Image
│
▼
Docker Container
│
▼
Running Application

Let's break this down.

Docker Client
The first component your command interacts with is the Docker Client.
Think of it as the messenger between you and Docker.

When you type: docker run nginx
The Docker Client doesn't create containers or download images. Its only responsibility is to receive your command and send it to the Docker Engine. A simple example is ordering food through an app. You place your order using the app, but the app doesn't prepare your meal. It simply sends your request to the restaurant: the Docker Client works exactly the same way.

Docker Engine
Once the Docker Client receives your command, it forwards it to the Docker Engine. If the Docker Client is the messenger, then Docker Engine is the brain. This is where the work happens.

The Docker Engine is responsible for:

Building Docker Images
Creating and starting Containers
Managing Docker Networks
Managing Docker Volumes
Pulling Images from Docker Registries

Without the Docker Engine, Docker simply cannot function. The first thing the Engine asks itself is: "Do I already have this image?"
If the answer is yes, Docker continues. If the answer is no, Docker needs somewhere to download it from. That's where Docker Hub comes in.

Docker Registry (Docker Hub)
A Docker Registry is simply a place where Docker Images are stored. The most popular registry is Docker Hub. Think of Docker Hub as GitHub but instead of hosting source code, it hosts Docker Images.
If Docker Engine can't find an image locally, it automatically reaches out to Docker Hub, downloads the image, stores it on your computer, and then continues the process. The nice thing is that Docker only downloads an image once.

The next time you run the same image, Docker simply uses the local copy, making the process much faster. Understanding this explains why your very first Docker command usually takes longer than every command after it.

Docker Images != Just a Blueprint
One of the most common explanations you'll hear is: "A Docker Image is a blueprint."
While that's true, it doesn't tell the whole story. A Docker Image is a complete, read-only package that contains everything your application needs to run.

That includes:

Your application code
Runtime (Python, Node.js, Java, etc.)
Dependencies
Required libraries
Configuration
Operating system packages

Think of it as a snapshot of your application at a particular point in time. Once an image is built, Docker treats it as immutable, meaning it doesn't change. If you modify your application, Docker doesn't update the existing image. Instead, it creates a completely new image.
At first, this might sound inefficient. In reality, it's one of Docker's biggest strengths. Because Images never change, every developer, testing environment, CI/CD pipeline, and production server runs exactly the same package.
That's one of the biggest reasons Docker became so popular: It removed the uncertainty of different environments.
Another important thing to know is that Images are not running. They simply exist, waiting to be used. You can think of an Image as a packaged application that's ready to be launched whenever you need it.

Docker Containers: Where Your Application Comes Alive
Here's something many beginners don't realize: docker never runs an Image directly. Instead, it creates a Container from that Image. A Container is simply the running instance of a Docker Image. Unlike Images, Containers are alive; they consume CPU; they use memory; they process requests; they respond to users.
They are the part that's actually executing your application. One of Docker's biggest advantages is that a single Image can create multiple Containers.

For example:

Every container starts from the exact same Image. That's why Docker delivers consistency. Instead of creating three different applications, Docker simply creates three running instances from the same package.
Containers are also designed to be temporary. If a container crashes, becomes corrupted, or is deleted, Docker doesn't expect you to repair it. You simply create another container from the original Image.
Since the Image never changed, the new Container behaves exactly like the previous one. This idea of treating containers as disposable is one of the biggest mindsets shifts Docker introduces. Instead of fixing running environments, you recreate them.

It's faster, cleaner and far more predictable.
Developer Tip: If there's one thing to remember from this section, let it be this:

Images are packages. Containers are running applications.
Docker never runs an Image directly; it always creates a Container from it.

Why Understanding These Concepts Matters Before Writing Your First Command
You may have noticed that we still haven't written a single Docker command and that's by design.
Learning Docker isn't about memorizing commands; it's about understanding what's happening every time you run one.
Once you understand how the Docker Client, Docker Engine, Docker Hub, Images, and Containers work together, Docker stops feeling complicated. The commands become logical because you know what's happening behind the scenes.

That's the purpose of this series: not just to teach you how to use Docker, but to help you understand why it works the way it does.
Now that we've built that foundation, it's time to put it into practice. In the next part, we'll build our first Docker Image and learn how a Dockerfile brings everything together.
.

What Is Lua AI? A Simple Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:55:51 +0000

Ladipo Samuel

Jul 1

What Is Lua AI? A Developer's Guide to Building AI Agents

#agents #ai #llm #programming

3 min read

A Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:54:27 +0000

Ladipo Samuel

Jul 1

What Is Lua AI? A Developer's Guide to Building AI Agents

#agents #ai #llm #programming

3 min read