DEV Community: Munir Ahmad

Fastlane for Flutter: Complete Local Setup for iOS and Android Deployments

Munir Ahmad — Mon, 14 Sep 2026 08:17:27 +0000

Stop manual store clicks. Learn how to configure Fastlane locally to build, guard, and ship your Flutter app to TestFlight and Google Play with a single command.

Why bother

Every Flutter release usually looks like this: bump the version, build the IPA, open Xcode, wait for the organizer, switch to browsers, build the AAB, drag-and-drop into the Play Console, and fill out release notes. It’s ten minutes of tedious clicking that changes every time, meaning it never becomes muscle memory.

Fastlane turns that entire ritual into:

bundle exec fastlane ios deploy 
bundle exec fastlane android deploy

This article is Part 1 : getting it working locally on your machine. Part 2 moves these exact lanes into GitHub Actions so a simple tag push handles the rest. Do this part first — the CI setup assumes your local lanes are already green.

What you’ll need

A Flutter app that already builds and runs
An Apple Developer account ($99/yr) with the app registered in App Store Connect
A Google Play Console account ($25 one-time) with the app created and at least one AAB uploaded manually — Play won’t accept the first-ever build over the API.
Ruby (macOS ships with one; a version manager like rbenv is nicer but not required)
Xcode with a valid signing setup for your app (Automatic signing with your team selected is fine for local)

I’m on FVM, so my Flutter SDK lives at /Users/<you>/fvm/versions/3.32.0. Note your own path now — you'll need it in a minute.

Step 1 — Install fastlane via a Gemfile (not globally)

You can brew install fastlane or gem install fastlane, but pinning it per-project with Bundler means your machine and your CI runner use the exact same version. Flutter projects have a ios/ and an android/ folder, and each gets its own Gemfile.

ios/Gemfile

source "https://rubygems.org"
gem "fastlane"
gem "cocoapods"

android/Gemfile

source "https://rubygems.org"
gem "fastlane"

The iOS Gemfile also pins CocoaPods so the build doesn’t depend on whatever pod version happens to be on the system (this matters a lot on CI later). Android has no such dependency, so its Gemfile stays minimal.

Install both:

cd ios && bundle install && cd ..
cd android && bundle install && cd ..

From here on, always call fastlane as bundle exec fastlane … so you get the pinned version.

Step 2 — Set FLUTTER_ROOT

fastlane’s iOS build scripts shell out to Flutter and need to know where the SDK is. Add this to your shell profile (~/.zshrc):

export FLUTTER_ROOT="/Users/<you>/fvm/versions/3.32.0"

If you’re not on FVM, it’s wherever which flutter points, minus /bin/flutter. Reload your shell (source ~/.zshrc) and confirm:

echo $FLUTTER_ROOT

Step 3 — Confirm the raw builds work

Before automating anything, make sure the two build commands fastlane will run actually succeed on their own:

fvm flutter build appbundle --release # Android -> build/app/outputs/bundle/release/app-release.aab

fvm flutter build ipa --release # iOS -> build/ios/ipa/<YourApp>.ipa

If flutter build ipa complains about signing, open ios/Runner.xcworkspace in Xcode once, select the Runner target → Signing & Capabilities, tick Automatically manage signing, pick your team, and let it create the profile. Then re-run. Don't move on until both commands produce an artifact.

Step 4 — `fastlane init` for iOS

# from app's root
cd ios
bundle exec fastlane init

Pick option 2 (Automate beta distribution to TestFlight). It parses your Xcode project, then asks you to log in with your Apple ID. This triggers a 2FA prompt on your trusted device — enter the 6-digit code. It’ll verify the app exists in both the Developer Portal and App Store Connect.

This creates ios/fastlane/Appfile and ios/fastlane/Fastfile.

Step 5 — `fastlane` init for Android

# from app's root
cd android
bundle exec fastlane init

It asks for your package name (must match applicationId in android/app/build.gradle), then asks for the path to a Play service account JSON. Press Enter to skip that for now — we'll wire it up properly in Step 6.

This creates android/fastlane/Appfile and android/fastlane/Fastfile.

Step 6 — Fill in the Appfiles

android/fastlane/Appfile

json_key_file("pc-key.json") # only used by validate/supply — the deploy lane uses the base64 env var
package_name("com.example.app") # must match applicationId in android/app/build.gradle

Now get the pc-key.json:

Open the Google Cloud APIs & Services page.
Enable the Google Play Android Developer API for that project.

Create the Service Account directly in Google Cloud

Open the Google Cloud IAM Service Accounts page.
Make sure you are logged into the Google account that manages this Play Store developer profile.
Select your Google Cloud project from the top dropdown (or create a quick project named “Play Store Fastlane” if none exists).
Click + CREATE SERVICE ACCOUNT at the top.
Enter fastlane-supply as the Service Account name and click DONE.
Copy the generated Service Account Email address (looks like fastlane-supply@your-project-id.iam.gserviceaccount.com).

Generate and download the JSON key:

Click on the newly created service account email in the list.
Click the Keys tab at the top.
Click ADD KEY > Create new key.
Choose JSON as the key type and click CREATE.
Save the downloaded .json file into your project's android/ directory as pc-key.json.

Grant access via Users and permissions:

Return to your Google Play Console tab.
Click Users and permissions from the left sidebar (the 3rd item from the top in your screenshot).
Click Invite new users at the top right.
Paste the Service Account Email you copied above into the email address field.
Under Account permissions , grant permissions for Release to testing tracks.
Click Invite user at the bottom right.

Verify the connection in Fastlane:

bundle exec fastlane run validate_play_store_json_key json_key:pc-key.json

Now base64-encode it into .env.deploy (this is what the lane actually uses, and the same value goes into GitHub Secrets later — one encoding, two homes):

base64 -i android/pc-key.json | tr -d '\n' | pbcopy
# paste into .env.deploy as: PLAY_STORE_JSON_KEY_BASE64=<pasted>

ios/fastlane/Appfile

app_identifier("com.example.app") # must match your bundle ID in Xcode
apple_id("you@example.com") # your Apple Developer account email
itc_team_id("1234567") # App Store Connect team ID
team_id("ABCDE12345") # Developer Portal team ID

If you don’t know the team IDs, run bundle exec fastlane spaceship or check the URLs in the App Store Connect / Developer portal — they're in there. These aren't secret, but people often redact them out of habit; your call.

Step 7 — iOS auth: use an App Store Connect API key, not your password

You’ll see guides that tell you to set FASTLANE_USER and FASTLANE_PASSWORD. Don't. With an Apple ID that has 2FA (all of them now do), that approach means:

constant 2FA prompts you can’t answer from a CI runner
sessions that expire every few days
the occasional locked account when Apple decides the login looks robotic

An App Store Connect API key sidesteps all of it — no 2FA, no expiry, and it’s scoped to just what it needs.

App Store Connect → Users and Access → Integrations → App Store Connect API.
Create a key with the App Manager role.
Download the AuthKey_XXXXXXXXXX.p8 — you can only download it once.
Note the Key ID and the Issuer ID shown on that page.

Encode the key and the two IDs into .env.deploy:

base64 -i AuthKey_XXXXXXXXXX.p8 | tr -d '\n' | pbcopy

# .env.deploy
APP_STORE_CONNECT_API_KEY_ID=XXXXXXXXXX
APP_STORE_CONNECT_API_ISSUER_ID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
APP_STORE_CONNECT_API_KEY_BASE64=<pasted>

Delete the downloaded .p8 once it's encoded — .env.deploy is now the only copy you keep, and it's gitignored. Apple only lets you download the .p8 once. If you lose it, revoke that key in App Store Connect and issue a new one.

Step 7B — the `.env.deploy` file

All deploy secrets live in foody-app/.env.deploy, which both Fastfiles load via dotenv at the top. It is gitignored; a committed .env.deploy.example documents every key. Your .gitignore should already have:

.env
.env.*
!.env.example
!.env.deploy.example
android/pc-key.json

.env.deploy.example also lists BUILD_CERTIFICATE_BASE64, P12_PASSWORD, BUILD_PROVISION_PROFILE_BASE64, KEYCHAIN_PASSWORD, APPLE_TEAM_ID — those are only for CI signing (Part 2). Locally, Xcode's managed signing handles it and you can leave them blank.

Step 8 — Write the deploy lanes

Replace the generated Fastfile in each folder with these.

fastlane init generates a placeholder Fastfile. Replace each with the version below. They share the same shape: load .env.deploy, check the store first , build with fvm flutter, upload.

android/fastlane/Fastfile

default_platform(:android)

require "dotenv"
deploy_env = File.expand_path("../../.env.deploy", __dir__ || File.dirname( __FILE__ ))
Dotenv.load(deploy_env) if File.exist?(deploy_env)

platform :android do
  desc "Automated build & deploy to Play Store Internal Track"
  lane :deploy do
    json_key_data = play_json_key_data
    guard_version_code_is_new(json_key_data)

    UI.message("🚀 Building Android App Bundle")

    Bundler.with_unbundled_env do
      sh("cd ../.. && fvm flutter build appbundle --release")
    end

    upload_build(json_key_data: json_key_data)
  end

  desc "Upload the already-built AAB to Play Console (skips Flutter build)"
  lane :upload do
    json_key_data = play_json_key_data
    guard_version_code_is_new(json_key_data)
    upload_build(json_key_data: json_key_data)
  end

  private_lane :upload_build do |options|
    app_root = File.expand_path("../..", __dir__ || File.dirname( __FILE__ ))
    aab_path = File.join(app_root, "build/app/outputs/bundle/release/app-release.aab")

    UI.user_error!("No .aab found at #{aab_path} — run `fastlane android deploy` or `flutter build appbundle` first") unless File.exist?(aab_path)

    upload_to_play_store(
      json_key_data: options[:json_key_data],
      track: "internal",
      aab: aab_path,
      skip_upload_metadata: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

def play_json_key_data
  b64 = ENV["PLAY_STORE_JSON_KEY_BASE64"].to_s
  UI.user_error!("PLAY_STORE_JSON_KEY_BASE64 missing from foody-app/.env.deploy") if b64.empty?
  require "base64"
  Base64.decode64(b64)
end

def pubspec_version
  pubspec = File.expand_path("../../pubspec.yaml", __dir__ || File.dirname( __FILE__ ))
  m = File.read(pubspec).match(/^version:\s*(\d+\.\d+\.\d+)\+(\d+)/)
  UI.user_error!("Could not read version from pubspec.yaml") unless m
  [m[1], m[2].to_i]
end

def guard_version_code_is_new(json_key_data)
  _, local = pubspec_version
  package = CredentialsManager::AppfileConfig.try_fetch_value(:package_name)

  seen = %w[production internal].flat_map do |track|
    begin
      google_play_track_version_codes(package_name: package, track: track, json_key_data: json_key_data)
    rescue => e
      UI.important("Could not read Play '#{track}' track (#{e.message})")
      []
    end
  end.map(&:to_i)

  max_live = (seen + [0]).max
  if local <= max_live
    UI.user_error!("pubspec versionCode #{local} is not ahead of Play's #{max_live} — run `cider bump build` first.")
  end
  UI.success("pubspec versionCode #{local} is ahead of Play (#{max_live}) ✓")
end

ios/fastlane/Fastfile

default_platform(:ios)

require "dotenv"
deploy_env = File.expand_path("../../.env.deploy", __dir__ || File.dirname( __FILE__ ))
Dotenv.load(deploy_env) if File.exist?(deploy_env)

platform :ios do
  desc "Build IPA and upload to TestFlight"
  lane :deploy do
    api_key = app_store_api_key
    guard_build_number_is_new(api_key)

    Bundler.with_unbundled_env do
      sh("cd .. && fvm flutter build ipa --release")
    end
    upload_build(api_key: api_key)
  end

  desc "Upload the already-built IPA to TestFlight (skips the Flutter build)"
  lane :upload do
    api_key = app_store_api_key
    guard_build_number_is_new(api_key)
    upload_build(api_key: api_key)
  end

  private_lane :upload_build do |options|
    app_root = File.expand_path("../..", __dir__ || File.dirname( __FILE__ ))
    ipa_path = Dir[File.join(app_root, "build/ios/ipa/*.ipa")].max_by { |f| File.mtime(f) }
    UI.user_error!("No .ipa found under #{app_root}/build/ios/ipa — run `fastlane ios deploy` or `flutter build ipa` first") unless ipa_path

    upload_to_testflight(
      api_key: options[:api_key],
      ipa: ipa_path,
      skip_waiting_for_build_processing: true,
      skip_submission: true
    )
  end
end

def app_store_api_key
  key_id = ENV["APP_STORE_CONNECT_API_KEY_ID"].to_s
  issuer_id = ENV["APP_STORE_CONNECT_API_ISSUER_ID"].to_s
  key_b64 = ENV["APP_STORE_CONNECT_API_KEY_BASE64"].to_s

  UI.user_error!("APP_STORE_CONNECT_API_KEY_ID missing from foody-app/.env.deploy") if key_id.empty?
  UI.user_error!("APP_STORE_CONNECT_API_ISSUER_ID missing from foody-app/.env.deploy") if issuer_id.empty?
  UI.user_error!("APP_STORE_CONNECT_API_KEY_BASE64 missing from foody-app/.env.deploy") if key_b64.empty?

  app_store_connect_api_key(
    key_id: key_id,
    issuer_id: issuer_id,
    key_content: key_b64,
    is_key_content_base64: true,
    in_house: false
  )
end

def pubspec_version
  pubspec = File.expand_path("../../pubspec.yaml", __dir__ || File.dirname( __FILE__ ))
  m = File.read(pubspec).match(/^version:\s*(\d+\.\d+\.\d+)\+(\d+)/)
  UI.user_error!("Could not read version from pubspec.yaml") unless m
  [m[1], m[2].to_i]
end

# Fail before the ~10-minute build if pubspec's +N was not bumped past what
# TestFlight already has for this marketing version.
def guard_build_number_is_new(api_key)
  name, local = pubspec_version
  begin
    live = latest_testflight_build_number(
      api_key: api_key,
      app_identifier: CredentialsManager::AppfileConfig.try_fetch_value(:app_identifier),
      version: name,
      initial_build_number: 0
    ).to_i
  rescue => e
    UI.error("Could not check TestFlight build numbers (#{e.message}) — skipping the guard; the store will still reject a reused build.")
    return
  end

  if local <= live
    UI.user_error!("pubspec build #{name}+#{local} is not ahead of TestFlight's #{live} — run `cider bump build` first.")
  end
  UI.success("pubspec #{name}+#{local} is ahead of TestFlight (#{live}) ✓")
end

.env.deploy at the top . Both files load it with dotenv before anything runs. On CI the same variables come from the environment, so the Fastfile doesn't change.
The guard_* check runs first, and hits the store API, not a build. flutter build ipa takes ~10 minutes. If you forgot to bump the version, the guard catches it in a couple of seconds — iOS asks TestFlight for the latest build number of the current marketing version; Android asks Play for the highest versionCode across the production and internal tracks. If your pubspec.yaml isn't ahead, it stops with "run cider bump build first."
app_store_api_key / play_json_key_data decode the base64 secret in memory. Nothing is ever written to disk.
Two lanes. deploy = build + upload. upload = upload the artifact that's already in build/, skipping the build — for when the upload failed and you don't want to wait 10 minutes again.
Bundler.with_unbundled_env { sh("… fvm flutter build …") } runs the Flutter build outside fastlane's Bundler context so Flutter/CocoaPods resolve against FVM cleanly.
iOS picks the newest build/ios/ipa/*.ipa by modified time rather than guessing the filename from the app's display name. It uploads with skip_submission (goes to TestFlight, not the App Store review queue) and skip_waiting_for_build_processing (don't block the terminal while Apple processes it).
Android uploads to the internal track and skips metadata/images/screenshots so the lane only touches the binary.

Step 9 — Bump the version and Changelog

Play and TestFlight both reject a build number that already exists. pubspec.yaml’s version: line — X.Y.Z+N — is the single source of truth for both the iOS CFBundleVersion and the Android versionCode, and +N is the value both stores check for uniqueness:

version: 1.0.0+1 # <marketing version> + <build number>

This project manages the version with cider, added as a dev-dependency:

dev_dependencies:
  cider: ^0.2.10

It’s a dependency, not a global tool, so run it through the SDK: fvm dart run cider …

While you work: log changes

cider collects entries under an ## Unreleased heading in CHANGELOG.md:

fvm dart run cider log added "Dark mode toggle in settings."
fvm dart run cider log fixed "Crash when opening an expired invite link."

(log subcommands: added, changed, deprecated, fixed, removed, security.)

At release time: bump once, then release

Step 1 — bump the version. Run one of these, never both:

fvm dart run cider bump build # same version, next build: 1.0.0+1 -> 1.0.0+2
fvm dart run cider bump patch --bump-build # new marketing version: 1.0.0+1 -> 1.0.1+2

minor and major work the same way:

cider bump minor --bump-build
cider bump major --bump-build

Always pass --bump-build on a marketing bump. A plain cider bump patch drops the +N build number, and Play Console rejects any upload whose versionCode isn’t higher than the last one shipped. To set a version explicitly:

fvm dart run cider version 1.4.0+37.

Step 2 — stamp the changelog:

fvm dart run cider release

cider release turns ##Unreleased into a dated heading. After cider bump build (->1.0.0+2) and the two log entries above, CHANGELOG.md becomes:

## 1.0.0+2 - 2026-09-10
### Added
- Dark mode toggle in settings.

### Fixed
- Crash when opening an expired invite link.

Commit just those two files and tag — the tag is what Part 2’s CI triggers on:

git add pubspec.yaml CHANGELOG.md
git commit -m "chore(release): v1.0.0+2"
git tag -a v1.0.0+2 -m "v1.0.0+2"
git push --follow-tags

Do this once per release, from a clean tree, then deploy both platforms from that commit.

Step 10 — Ship it

# from app's root
cd android && bundle exec fastlane deploy && cd ..
cd ios && bundle exec fastlane deploy && cd ..

Both lanes read foody-app/.env.deploy. If a build fails at upload, rerun just bundle exec fastlane <platform> upload — it skips the 10-minute rebuild.

Troubleshooting the first run

flutter or fvm: command not found inside a lane: Ensure FVM is added to your shell's PATH where you launch Fastlane.
invalid curve name / .p8 key errors: Your Base64-encoded key string contains hidden line breaks. Re-encode it cleanly:

base64 -i key.p8 | tr -d '\n'

versionCode N is not ahead of Play's M: You skipped the version bump step. Run fvm dart run cider bump patch --bump-build, commit, and retry.
*_missing from .env.deploy errors: Fastlane cannot locate your environment file. Ensure .env.deploy sits directly at your app's root directory (foody-app/.env.deploy), not inside ios/ or android/.

What’s next — Part 2

Part 2 moves this exact workflow to GitHub Actions. Because every secret is already a base64 string in .env.deploy, CI is mostly “same variables, sourced from GitHub Secrets instead of the file.” The additions are: the iOS signing vars from .env.deploy.example (BUILD_CERTIFICATE_BASE64, P12_PASSWORD, BUILD_PROVISION_PROFILE_BASE64, KEYCHAIN_PASSWORD), a step that builds a throwaway keychain on the runner, and a workflow triggered by the v* tag you push in Step 9. The Fastfiles don't change at all.

Ten minutes of tedious web console clicking are now permanently replaced by a single command. Your local release pipeline is fully automated, version-guarded, and bulletproof.

Up next in Part 2 , we’ll take these exact lanes, move them to the cloud, and wire them up to GitHub Actions so a simple tag push handles the rest. Let’s ship code faster! 🚀

Use Multiple GitHub Accounts on One Machine (SSH)

Munir Ahmad — Sun, 14 Dec 2025 15:01:47 +0000

A step-by-step guide to seamlessly manage multiple GitHub accounts with SSH keys.

Managing Multiple GitHub Accounts on One Machine Using SSH

If you use both personal and work GitHub accounts on the same machine, authentication issues are almost inevitable. Commits go to the wrong account, pushes fail, or Git keeps asking for credentials.

The clean solution is simple: one SSH key per account, configured once, and reused forever. This guide shows how to do exactly that.

What You’ll Learn

Create separate SSH keys for each GitHub account
Configure SSH to automatically select the correct identity
Clone, push, and commit without account conflicts

Applies to: macOS and Linux (Windows users via WSL or Git Bash can follow the same steps)

Prerequisites

Git installed
Basic terminal knowledge
Access to multiple GitHub accounts

Step 1: Generate a Dedicated SSH Key

Create a new key for your work account:

ssh-keygen -t ed25519 -C "work@email.com" -f ~/.ssh/id_ed25519_work

This avoids overwriting existing keys and clearly separates identities.

When prompted, adding a passphrase is recommended for security.

Generated files:

id_ed25519_work — private key (keep secret)
id_ed25519_work.pub — public key (add to GitHub)

Step 2: Add the Key to the SSH Agent

Start the agent and load your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_work

This allows Git to authenticate without repeatedly asking for a passphrase.

Step 3: Add the Public Key to GitHub

Copy your public key:

cat ~/.ssh/id_ed25519_work.pub

Copy the entire output (starts with ssh-ed25519).

Navigate to: https://github.com/settings/keys
Click New SSH key
Add a title (e.g., “Work Laptop — 2024”)
Paste your public key
Click Add SSH key

Highlighting where to add your SSH key in GitHub settings.

Step 4: Configure SSH Host Aliases

Edit your SSH config:

nano ~/.ssh/config

Add:

# Here you can add multiple identities personal, work etc.
# Personal account
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

# Work account
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

This tells SSH exactly which key to use for each account.

Step 5: Test the Setup

ssh -T github-work

If successful, GitHub will confirm authentication. Expected output:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Using the Correct Account

Clone Repositories

# Work account
git clone git@github-work:company/repo.git

# Personal account
git clone git@github.com:username/repo.git

Fix an Existing Repository

git remote set-url origin git@github-work:company/repo.git

Set Commit Identity (Per Repository)

git config user.name "Your Name"
git config user.email "work@company.com"

This ensures commits are attributed correctly.

Final Thoughts

Managing multiple GitHub accounts doesn’t require hacks or workarounds.

With one SSH key per account and a clear SSH configuration , Git becomes invisible — and that’s exactly how tooling should behave.

Configure it once. Forget about it forever.

Secure Swagger & ReDoc in Django REST Framework with DRF Spectacular: Best Practices for API…

Munir Ahmad — Sun, 07 Dec 2025 17:56:18 +0000

Secure Swagger & ReDoc in Django REST Framework with DRF Spectacular: Best Practices for API Security

API documentation tools like Swagger UI and ReDoc make development easier, but they also expose every endpoint, schema, and request structure to anyone who can access the URL.

If you deploy your Django REST Framework project without protecting /api/docs/ or /api/schema/, you're unintentionally giving outsiders:

A complete map of all your APIs
All request/response structures
Authentication patterns
Internal admin/debug endpoints

This makes exploitation easier and increases your attack surface.

That’s why Swagger must never be public in production. In this guide, we’ll show a clean, secure way to protect your API documentation using DRF Spectacular in a Django REST Framework project.

A secure architecture for safeguarding Swagger and ReDoc in DRF using DRF Spectacular.

# Directory structure
core/
    docs/
        swagger_view.py
    urls.py
    settings.py

core/docs/swagger_view.py

from django.shortcuts import redirect
from drf_spectacular.views import (
    SpectacularAPIView,
    SpectacularSwaggerView,
    SpectacularRedocView,
)

class AdminOnlyMixin:
    """
    Restrict access to authenticated superusers.
    """

    def dispatch(self, request, *args, **kwargs):
        if not request.user.is_authenticated:
            return redirect(f"/admin/login/?next={request.path}")
        if not request.user.is_superuser:
            return redirect("/403/") # Make sure a 403 page exists
        return super().dispatch(request, *args, **kwargs)

class SuperuserSchemaView(AdminOnlyMixin, SpectacularAPIView):
    pass

class SuperuserSwaggerView(AdminOnlyMixin, SpectacularSwaggerView):
    pass

class SuperuserRedocView(AdminOnlyMixin, SpectacularRedocView):
    pass

core/urls.y

from django.urls import path
from core.docs import (
    SuperuserRedocView,
    SuperuserSchemaView,
    SuperuserSwaggerView,
)

urlpatterns = [
    # API documentation (protected)
    path("api/schema/", SuperuserSchemaView.as_view(), name="schema"),
    path("api/docs/", SuperuserSwaggerView.as_view(url_name="schema"), name="swagger-ui"),
    path("api/redoc/", SuperuserRedocView.as_view(url_name="schema"), name="redoc"),
]

core/settings.py

REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        # JWT for external API clients
        "rest_framework_simplejwt.authentication.JWTAuthentication",

        # Session auth so Swagger works automatically after admin login
        "rest_framework.authentication.SessionAuthentication",
    ),
    "DEFAULT_PERMISSION_CLASSES": (
        "rest_framework.permissions.IsAuthenticated",
    ),
    "DEFAULT_SCHEMA_CLASS": "drf_spectacular.openapi.AutoSchema",
}

SPECTACULAR_SETTINGS = {
    "TITLE": "Your API",
    "DESCRIPTION": "API documentation",
    "VERSION": "1.0.0",

    # Allow our custom view to control permissions manually
    "SERVE_PERMISSIONS": ["rest_framework.permissions.IsAdminUser"],

    # Use DRF’s normal authentication classes (Session + JWT)
    "SERVE_AUTHENTICATION": None,

    # Important: Do NOT expose schema automatically in unrestricted mode
    "SERVE_INCLUDE_SCHEMA": False,
}

Notes:

SessionAuthentication allows admin users to access protected docs easily.
SERVE_INCLUDE_SCHEMA = False ensures your schema isn’t automatically exposed.

And that’s the real value of securing your API documentation: you empower your team without empowering your attackers. When Swagger and ReDoc live behind proper authentication, your developers gain clarity, your system gains integrity, and your attack surface quietly shrinks. Secure the docs, protect the blueprint, and let your API evolve with confidence — exactly the way production-grade engineering should be. Appreciate your time. Until next time 👋.

Install the Latest PostgreSQL (psql 18) on Ubuntu 24.04 (Noble)

Munir Ahmad — Mon, 03 Nov 2025 17:40:16 +0000

Why I Wrote This

While setting up my development environment on Ubuntu 24.04 (Noble Numbat), I noticed the default PostgreSQL version in Ubuntu’s repository was outdated.

So I decided to document the clean, official way to install the latest PostgreSQL (v18) — straight from the PostgreSQL Apt repository.

If you’ve ever run into issues like:

“No cluster suitable as a default target”
or old versions like PostgreSQL 14 or 15 being installed instead of the latest then this guide will help you start fresh.

Step-by-Step Guide to Installing PostgreSQL 18

Step 1 — Update and Upgrade Your System

sudo apt update && sudo apt upgrade -y

Step 2 — Check Your Ubuntu Codename:

PostgreSQL’s official repo depends on your Ubuntu version codename.

Run the following to check yours:

. /etc/os-release
echo $VERSION_CODENAME

For Ubuntu 24.04, the output should be:

noble

Step 3 — Install Required Packages

We’ll install curl, ca-certificates, and postgresql-common:

sudo apt install -y curl ca-certificates postgresql-common

Step 4 — Add the PostgreSQL Apt Repository

Run the following command to automatically add the official PostgreSQL repository:

sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

Step 5 — Update Package Lists & Install PostgreSQL 18

sudo apt update
sudo apt install -y postgresql-18

When prompted during installation:

Type Y to confirm.
If you see a purple configuration screen like this 👇 choose “install the package maintainer’s version” (This ensures a clean, default setup for PostgreSQL 18.)

Step 7 — Verify Installation

Check the installed version you should see:

psql --version
psql (PostgreSQL) 18.x

That’s it! You’ve successfully installed and verified PostgreSQL 18 on Ubuntu 24.04 (Noble).

Your system is now running the latest, officially supported PostgreSQL version, ready for use in production or local development.If you encounter any issues, check the PostgreSQL service logs with:

sudo journalctl -u postgresql

Otherwise — you’re all set to start building with PostgreSQL 18.