DEV Community: Dedar Alam

Zero to Production: FastAPI on Fly.io and GitHub Actions

Dedar Alam — Fri, 03 Jul 2026 14:47:07 +0000

Zero to Production: FastAPI on Fly.io with a YAML Config and GitHub Actions

You push to main, tests run, and a couple of minutes later your API is live. This post builds that pipeline end to end — one FastAPI app, one Docker image, one YAML config file, one GitHub Actions workflow. No database, no Redis, no extra services: just the app, deployed properly.

The Big Picture

git push → GitHub Actions → run tests → build image → deploy to Fly.io → live

Three moving parts:

Your FastAPI app, packaged in a Docker image so it runs identically everywhere.
Fly.io, which takes that image and runs it on small VMs called Machines — handling TLS, routing, health checks, and restarts.
GitHub Actions, which watches the repo and runs the deploy automatically on every push to main.

The glue is a scoped deploy token: a Fly API token stored as a GitHub secret so the CI runner can deploy on your behalf — and nothing else.

A note on the config file before we start: Fly's docs default to fly.toml, but flyctl accepts TOML, YAML, or JSON — the structure is identical. We'll use YAML (fly.yaml) throughout. The only consequence is that since flyctl looks for fly.toml by default, we pass --config fly.yaml explicitly. That's a feature, not a chore: being explicit about which config you're deploying is exactly the habit that later scales into fly.stg.yaml / fly.prod.yaml multi-environment setups.

Step 0: Prerequisites

A FastAPI project in a GitHub repo
The flyctl CLI (curl -L https://fly.io/install.sh | sh)
A Fly.io account (fly auth signup or fly auth login)

Project layout:

myapi/
├── app/
│   ├── __init__.py
│   └── main.py
├── tests/
│   └── test_main.py
├── requirements.txt
├── Dockerfile
├── fly.yaml
└── .github/
    └── workflows/
        └── deploy.yml

And a minimal app with a health endpoint (we'll need it later — it's not decoration):

# app/main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/health")
def health():
    return {"status": "ok"}

Step 0.5: `requirements.txt`

The Dockerfile in the next step installs from this file, so it needs to exist first. Minimal set for a FastAPI app served by uvicorn:

fastapi==0.115.6
uvicorn[standard]==0.34.0

uvicorn[standard] pulls in uvloop and httptools, which make it noticeably faster than the bare install — worth it even for a small API. If your app talks to a database or reads config from environment variables, you'd typically add:

pydantic-settings==2.7.1
python-dotenv==1.0.1

Pin versions (==, not bare package names). Without pins, a random future pip install in CI or in the Fly builder can pull a newer major version that breaks your app on deploy — exactly the kind of thing you want caught by pytest locally, not discovered in production. Generate pins from a working local environment with:

pip freeze > requirements.txt

then trim it down to what your app actually imports — pip freeze also captures transitive dependencies and anything else installed in that environment, which bloats the file and makes upgrades harder to reason about.

Step 1: Dockerize the App

Fly deploys Docker images, so the Dockerfile is the deployment definition:

FROM python:3.12-slim

# Don't run as root
RUN useradd --create-home appuser
WORKDIR /home/appuser

# Install deps first so this layer is cached between builds
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app/ ./app/
USER appuser

EXPOSE 8080
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8080"]

Two details that matter on Fly:

Bind to 0.0.0.0, not 127.0.0.1. Fly's proxy connects from outside the container; localhost-only binding is the #1 cause of "deployed but unreachable."
Pick a port and stay consistent. We use 8080 here, and the config below must point at the same number.

Sanity-check locally before touching the cloud:

docker build -t myapi .
docker run -p 8080:8080 myapi
curl localhost:8080/health

Step 2: Create the Fly App and Write `fly.yaml`

First register the app (this only creates the name — no machines yet):

fly apps create myapi

Then write the config by hand. This is the whole file:

# fly.yaml
app: myapi
primary_region: fra        # pick a region close to your users

http_service:
  internal_port: 8080      # must match the port uvicorn binds to
  force_https: true
  auto_start_machines: true
  auto_stop_machines: stop # scale to zero when idle
  min_machines_running: 0
  checks:
    - interval: 15s
      timeout: 2s
      grace_period: 10s
      method: GET
      path: /health

vm:
  - size: shared-cpu-1x    # shared CPU is fine for I/O-bound APIs
    memory: 512mb

Walking through the blocks:

http_service tells Fly's edge proxy to route public HTTPS traffic to port 8080 inside your machines. force_https redirects any plain-HTTP request; TLS certificates are handled for you. The auto_stop / auto_start / min_machines_running: 0 trio means the app scales to zero when idle and wakes on the next request — essentially free while nobody's using it.

checks is the health check, and it's the most important block in the file. Fly only routes traffic to a machine once GET /health returns 200 — and during a deploy, it won't kill the old machine until the new one passes. That's zero-downtime deployment, given to you for the price of one endpoint.

vm is the machine sizing. Without it you get Fly's default; with it, the specs are version-controlled and enforced on every deploy:

size: shared-cpu-1x — shared CPUs are cheap and fine for I/O-bound APIs (which is what most FastAPI services are: the process waits on the network, it doesn't burn CPU). Move to performance-* sizes only for genuinely CPU-heavy work.
memory: 512mb — a comfortable floor for Python + uvicorn. 256MB works for tiny apps but leaves little headroom; RAM is usually the first limit you hit. Watch fly logs for OOM kills once real traffic arrives.

For quick experiments there's also an imperative route (fly scale vm shared-cpu-1x --memory 1024, fly scale count 2), but the config file wins: the next deploy resets machines to whatever fly.yaml says. Treat fly scale as a sandbox and the YAML as the source of truth.

One YAML footgun to know about: env vars and some values must be strings, so if you ever add a numeric-looking value, quote it ("8080", "0.0"). Unquoted, YAML parses it as a number and flyctl may reject it.

Step 3: First Manual Deploy

Automating a deploy you've never run by hand is debugging two systems at once. So first:

fly deploy --config fly.yaml
fly status --config fly.yaml
curl https://myapi.fly.dev/health

Note the --config fly.yaml — without it, flyctl looks for fly.toml and fails. Every fly command that touches the app takes the same flag (or --app myapi).

If your app needs credentials (API keys, a JWT secret), they never go in fly.yaml — the file is committed to git. They go in Fly's encrypted secret store and arrive as environment variables:

fly secrets set JWT_SECRET="..." --app myapi

Rule of thumb: if leaking it would matter, it's a secret; otherwise it can live in the config.

Step 4: The Deploy Token

The GitHub Actions runner needs permission to deploy — but never your personal credentials. Fly issues scoped tokens:

fly tokens create deploy -a myapi -x 720h

-a myapi scopes the token to this one app — it cannot touch any other app in your org.
-x 720h sets an expiry (30 days). Tokens default to 20 years if you omit -x, so always set a shorter one deliberately; a short-lived leak does far less damage than a permanent one.

This prints a token like FlyV1 fm2_lJPECAAAAAAAA... — copy the whole string, including the FlyV1 prefix.

Don't use fly auth token for this. That command returns your personal, all-powerful token — access to every app in your org — and it's deprecated for exactly this reason. Deploy tokens exist so a leaked CI secret has a blast radius of one app, not your whole account.

Store it in GitHub as a repository secret, not anywhere in the code:

Repo → Settings → Secrets and variables → Actions
New repository secret
Name: FLY_API_TOKEN (must match the name used in deploy.yml exactly)
Value: the full token string
Add secret

GitHub encrypts it at rest and masks it in logs; ${{ secrets.FLY_API_TOKEN }} in the workflow pulls it in as an env var at deploy time only. To rotate it later: fly tokens list -a myapi to find the ID, fly tokens revoke <id> to kill it, then repeat the steps above with a fresh token.

Step 5: The GitHub Actions Workflow

The heart of the pipeline — .github/workflows/deploy.yml (this one really is YAML by requirement; GitHub Actions speaks nothing else):

name: CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest httpx ruff

      - name: Lint
        run: ruff check app/

      - name: Run tests
        run: pytest -v

  deploy:
    needs: test                              # no green tests, no deploy
    if: github.ref == 'refs/heads/main'      # deploy from main only, never PRs
    runs-on: ubuntu-latest
    concurrency: deploy-group                # never two deploys at once
    steps:
      - uses: actions/checkout@v4

      - uses: superfly/flyctl-actions/setup-flyctl@master

      - name: Deploy to Fly.io
        run: flyctl deploy --remote-only --config fly.yaml
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

Reading it top to bottom:

Triggers. Every push to main and every PR targeting main runs the workflow. PRs get tests only; merges to main get tests and deploy. So every change is verified before merge, and every merge ships automatically.
needs: test makes deployment conditional on green tests — the whole point of CI/CD. A broken build physically cannot reach production.
if: github.ref == 'refs/heads/main' double-guards the deploy job so PR runs never deploy.
concurrency: deploy-group queues a second push behind an in-flight deploy instead of racing it.
--remote-only builds the Docker image on Fly's builders rather than inside the Actions runner — faster, and no Docker setup needed in CI.
--config fly.yaml — same flag as your manual deploy. The pipeline runs exactly the command you already trust.

A matching test so the gate has something real to check:

# tests/test_main.py
from fastapi.testclient import TestClient
from app.main import app

client = TestClient(app)

def test_health():
    r = client.get("/health")
    assert r.status_code == 200
    assert r.json() == {"status": "ok"}

Step 6: Push and Watch It Go

git add .
git commit -m "Add CI/CD pipeline"
git push origin main

Open the repo's Actions tab: checkout → lint → tests → deploy. When the last step goes green, https://myapi.fly.dev/health is serving the new code. From now on, your entire release process is: merge to main.

Day-2 Operations

Commands you'll actually use once this runs:

fly logs --app myapi                    # live application logs
fly status --app myapi                  # machine states, deployed version
fly releases --app myapi                # deployment history
fly deploy --image <ref> --config fly.yaml   # roll back to a previous image
fly ssh console --app myapi             # shell into a running machine

When a deploy goes bad, the health check usually saves you: the new machine never passes /health, traffic stays on the old one, and the failure shows up loudly in the Actions log instead of silently in production.

Where This Grows Next

The YAML habit pays off as soon as the app stops being alone:

Staging + production: duplicate the file as fly.stg.yaml and fly.prod.yaml, point each at its own Fly app with its own deploy token, and add a second deploy job gated on a develop branch. Same skeleton, one --config flag apart.
Background workers: a processes: block lets one image run both uvicorn and a task worker on separately sized machines.
Databases: attach Postgres or Redis as separate Fly apps on the private network, unreachable from the internet.
Hardening the pipeline: add pip-audit or trivy to the test job, and a coverage threshold to pytest.

But the skeleton never changes: a Dockerfile, a fly.yaml, a deploy.yml, and one scoped token. That's the entire distance between "runs on my laptop" and "ships on every merge."

Introducing HTTP Tracker Plus: Request Capture form Browser

Dedar Alam — Thu, 08 Jan 2026 12:50:25 +0000

API inspectors and debuggers are essential tools for web application development. Being able to inspect API requests and responses makes debugging much easier and more effective.

I often use Chrome DevTools to check request and response data. I have also been using HTTP Tracker, but one important feature was missing: capturing the response body.Since HTTP Tracker is open source, I spent a long time exploring the codebase and trying to implement this feature, but I was not successful at first.

I finally found a solution by using Chrome Debugger Mode, which makes it possible to capture the response body. While working on this, I also improved the UI to make it clearer and easier to use.

The update includes:
Response body capture for selected requests only
UI improvements for better readability and usage

I plan to publish this version to the Chrome Store and also submit a PR to the original project so others can benefit from it.
I have added a short GIF demo to show how it works.
GitHub repository (check the new branch): https://github.com/devded/http-tracker-plus
Feedback and suggestions are welcome.

How to Host Images with Dropbox

Dedar Alam — Sat, 17 May 2025 09:18:41 +0000

If you’ve ever needed a quick and reliable way to host an image online—for use in HTML, Markdown files, or just sharing directly—Dropbox can help! In this guide, I’ll walk you through how to turn a Dropbox image link into a direct image URL that can be used anywhere online.

📌 Step-by-Step: Hosting Images on Dropbox

1. Upload Your Image

First, go to your Dropbox account and upload the image you want to host. You can drag and drop it into your Dropbox folder or use the upload button.

2. Create a Shareable Link

Hover over the image.
Click the “Share” button.
Then, in the popup, click “Create link” and “Copy link.”

This will give you a link like this:

https://www.dropbox.com/s/abcd1234/your-image.jpg?dl=0

3. Modify the Link for Direct Access

To make the image load directly (instead of going to a Dropbox preview page), you need to change the end of the URL:

Change ?dl=0 to ?raw=1 OR
Replace www.dropbox.com with dl.dropboxusercontent.com

So the final direct link might look like:

https://dl.dropboxusercontent.com/s/abcd1234/your-image.jpg

✅ Use This Link Anywhere!

You can now use this link as the image source in HTML like so:

<img src="https://dl.dropboxusercontent.com/s/abcd1234/your-image.jpg" alt="My Image">

🔧 Bonus: Use a Tool to Convert It Automatically

Not a fan of editing URLs manually? No worries. Try this simple tool:

👉 dropboxlink.vercel.app

Just paste your Dropbox share link, and it will instantly give you the direct image URL!

That’s it! With Dropbox and a tiny tweak, you’ve got yourself a reliable image host. Great for blogging, portfolio sites, or sharing graphics with friends.

SS7 Attacks: Is Your Phone Really Safe?

Dedar Alam — Mon, 30 Sep 2024 16:16:44 +0000

Did you know your phone calls and text messages might be intercepted without your knowledge? The SS7 Attack is a significant cybersecurity threat that takes advantage of vulnerabilities in the global telecom infrastructure.

SS7 (Signaling System No. 7) is the protocol used by mobile networks to route calls and messages across carriers worldwide. It was designed decades ago, long before modern cyber threats, leaving it exposed to hackers and cybercriminals.

🔍 How Does the SS7 Attack Work?

Unauthorized Access: Hackers gain entry into the SS7 network.
Interception: They can intercept your phone calls, SMS messages, and even sensitive two-factor authentication (2FA) codes.
Real-Time Tracking: With just your phone number, hackers can track your location in real-time.
Call Redirection: They can redirect or block calls without you realizing it.

💼 Why Is This Important?

Imagine someone thousands of miles away listening to your private calls, reading your messages, or accessing your financial information by intercepting your 2FA codes. SS7 attacks have been used for everything from espionage to financial fraud.

🛡 How to Protect Yourself

Avoid SMS-based 2FA: Switch to app-based authentication like Google Authenticator or Authy for added security.
Use Encrypted Messaging Apps: For secure communication, use apps with end-to-end encryption like Signal or WhatsApp.
Enhance Privacy Settings: Regularly review and update your phone's privacy settings to minimize exposure.

While telecom companies are working on solutions, this is a reminder that our digital world is not always as secure as it seems. Stay informed, stay vigilant, and protect your data! 💡

🎬 Demo by Veritasium

Exploring Language Models with Gitpod & Ollama

Dedar Alam — Mon, 11 Dec 2023 16:52:48 +0000

Ever fantasized about embarking on an adventurous journey with your very own chat-GPT-style model? Open-source Large Language Models (LLMs) are at your disposal for exploration. In this guide, I'll guide you through setting up a playground using Gitpod and Ollama, turning your coding dreams into an exciting reality!

Setting Things Up:

Create a GitHub Playground:
Start your coding adventure by creating a new repository on GitHub. Consider it your coding playground where you can freely experiment with a variety of cool stuff.

Unlock Gitpod's Magic:
Open this repository in Gitpod by adding gitpod.io# to the beginning of your GitHub repository link. Witness as Gitpod works its magic, setting up a ready-to-use coding space just for your explorations.

Embarking on the Exploration:

Install Ollama:
With Gitpod ready, infuse your coding space with the magic of Ollama by entering this command in the terminal:


curl https://ollama.ai/install.sh | sh

Set the Ollama Stage:
Make your model accessible by typing the following commands in the terminal:

ollama

ollama serve

Choosing Your Adventure Companion:

Navigate to Ollama's library (https://github.com/jmorganca/ollama#model-library) and choose a model. These models are like adventurous chat buddies, capable of understanding and generating language. For this exploration, let's go with the starling-lm model.

ollama run starling-lm

Witness the magic unfold as your new language companion eagerly joins in on the exploration! Feel free to experiment with different prompts, ask intriguing questions, or weave captivating tales. The possibilities are as vast as your imagination.

Simplifying Web Application Middleware with Flowcharts

Dedar Alam — Sat, 17 Jun 2023 15:28:56 +0000

Web application middleware plays a crucial role in enhancing security and enabling various functionalities. Two commonly used middleware components are authentication and Cross-Origin Resource Sharing (CORS) middleware. In this blog post, we will explore how to visualize the flow of these middleware components using flowcharts, providing a clear understanding of the process. We will use the popular Mermaid syntax to create the flowcharts.

Understanding the Flowchart Components:

Start: The starting point of the flowchart.

Nodes: Represent specific steps or actions in the middleware process.

Arrows: Indicate the flow of the process from one step to another.
Decision Points: Represent conditional branches in the flow.

End: The final point of the flowchart.

Step 1: Receiving the Request:
At the start of the flowchart, the web server receives a request from the client.
This step serves as the entry point for the middleware process.

Step 2: Applying Authentication Middleware:

The received request is passed through the authentication middleware.
The authentication middleware validates the user's credentials and determines if the request is authenticated.
If the request is authenticated, the flow continues to the next step. Otherwise, an error response may be sent back to the client.
Step 3: Applying CORS Middleware:

After authentication, the request proceeds to the CORS middleware component.
The CORS middleware checks the request headers for CORS-related information.
Based on the CORS headers, the middleware determines whether the request is valid or not.

Step 4: Checking CORS Headers:

If the CORS headers are valid, the flow proceeds to respond with the requested resource.
However, if the CORS headers are invalid, an error response indicating a CORS issue is sent back to the client.

Step 5: Handling Error (Optional):

If an error occurs during the middleware process, such as a CORS error, an error-handling step is triggered.
The error-handling step determines whether to report the error or handle it internally.
If the error is reported, the client can send an error report to the server.
The server responds with an error handling response, which may provide additional information or guidance.

Step 6: Finalizing the Process:

After error handling or responding with the requested resource, the flow reaches its end.
The middleware process is completed, and the server can proceed with further actions, if necessary.

How ChatGPT Work

Dedar Alam — Sun, 26 Feb 2023 17:16:59 +0000

As an AI language model, ChatGPT work by processing and analyzing vast amounts of text data using machine learning algorithms to understand natural language and generate responses to user inputs.

Here's a brief overview of how it work:

Training Data: It was trained on a large corpus of text data, such as books, articles, and web pages. The training data was pre-processed to remove noise, such as HTML tags, punctuation, and stopwords.

Language Model Architecture: It based on a transformer architecture, which is a type of deep neural network designed for natural language processing. The transformer architecture uses a sequence-to-sequence approach that is particularly effective for tasks such as machine translation and text generation.

Tokenization: When you send a message, it first tokenize it into a sequence of tokens or subwords. This process breaks down the text into smaller units that are easier for the model to process.

Encoding: The tokenized input is then passed through an encoder, which generates a sequence of contextualized embeddings that capture the meaning and context of each token.

Decoding: The contextualized embeddings are then passed through a decoder, which generates a response based on the input and the knowledge stored in the model.

Post-Processing: The generated response is then post-processed to remove any noise or redundant information, such as repeating phrases or meaningless filler words.

Response Delivery: The final response is delivered to the user in natural language form.

It's important to note that ChatGPT responses are only as good as the data it was trained on, so there may be instances where it don't understand or correctly respond to your input. Nonetheless, it'll do it best to provide helpful and informative responses to your questions!

This blog is written with the help of ChatGPT 🫰

Git Cherry Pick

Dedar Alam — Mon, 30 Jan 2023 18:53:17 +0000

git cherry-pick

Check out the branch you want to apply the changes to: git checkout
Use git log to find the commit hash of the change you want to apply
Run git cherry-pick to apply the change to your current branch

For example:

$ git checkout my-feature-branch
$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: John Doe <johndoe@example.com>
Date:   Mon Mar 5 15:14:15 2021 -0800

Add new feature X

$ git cherry-pick ca82a6dff817ec66f44342007202690a93763949

This will apply the changes from the specified commit to the current branch. If there are any conflicts, Git will prompt you to resolve them before committing the cherry-picked changes.

How to revert git commit easily

Dedar Alam — Fri, 16 Sep 2022 19:48:03 +0000

First check the git log by running the command git log --oneline

Here you can see last six commit of this git repository.

add hello file this commit for add the hello file
and after this commit last five commit i add five line

Now i want to revent the line 5 commit.
I add this line on 1009bb3 add line 5 commit.
here
1009bb3 - commit hash
add line 5 - commit message

so next step is run revert command git revert --no-commit <commit hash>
here our revert command is git revert --no-commit 1009bb3

After run the revert commit, line 6 is gone. now i have to commit the revert commit changes

here commit all the changes after run revert commit

now time to check git log. now here one new commit add Revert "add line 5"

Reference Source

Commit case-sensitive only filename changes in Git

Dedar Alam — Thu, 28 Oct 2021 16:53:54 +0000

Suppose you have a folder name Dashboard you changed it to dashboard default configuration git doesn't recognize that change. Same things happens to files.

For that need to clean the cache, after struggle few hours I found a simple workable solution.

Here it is

git rm -r --cached .
git add --all .
git commit -a -m "Versioning untracked files"
git push

source Issue

Set up .env in react project tips

Dedar Alam — Sun, 24 Oct 2021 18:54:47 +0000

Found this tips while i'm fetching issue set up .env variable in react project

The .env file should be in the root for you application folder. That is one level above your src folder, the same place where you have your package.json
The variable should be prefixed with REACT_APP_ You need to restart the server to reflect the changes in your code.
You should access the variable in your code like this process.env.REACT_APP_SOME_VARIABLE
No need to wrap your variable value in single or double quotes.
Do not put semicolon ; or comma , at the end of each line.

Source One
Source Two

Commit case-sensitive only filename changes in Git

Dedar Alam — Tue, 12 Oct 2021 19:44:24 +0000

Suppose you have a folder name Dashboard you changed it to dashboard default configuration git doesn't recognize that change. Same things happens to files.

For that need to clean the cache, after struggle few hours I found a simple workable solution.

Here it is

git rm -r --cached .
git add --all .
git commit -a -m "Versioning untracked files"
git push

source

DEV Community: Dedar Alam

Zero to Production: FastAPI on Fly.io and GitHub Actions

Zero to Production: FastAPI on Fly.io with a YAML Config and GitHub Actions

The Big Picture

Step 0: Prerequisites

Step 0.5: requirements.txt

Step 1: Dockerize the App

Step 2: Create the Fly App and Write fly.yaml

Step 3: First Manual Deploy

Step 4: The Deploy Token

Step 5: The GitHub Actions Workflow

Step 6: Push and Watch It Go

Day-2 Operations

Where This Grows Next

Introducing HTTP Tracker Plus: Request Capture form Browser

How to Host Images with Dropbox

📌 Step-by-Step: Hosting Images on Dropbox

1. Upload Your Image

2. Create a Shareable Link

3. Modify the Link for Direct Access

✅ Use This Link Anywhere!

🔧 Bonus: Use a Tool to Convert It Automatically

SS7 Attacks: Is Your Phone Really Safe?

🔍 How Does the SS7 Attack Work?

💼 Why Is This Important?

🛡 How to Protect Yourself

🎬 Demo by Veritasium

Exploring Language Models with Gitpod & Ollama

Simplifying Web Application Middleware with Flowcharts

How ChatGPT Work

Git Cherry Pick

How to revert git commit easily

Commit case-sensitive only filename changes in Git

Set up .env in react project tips

Commit case-sensitive only filename changes in Git

Step 0.5: `requirements.txt`

Step 2: Create the Fly App and Write `fly.yaml`