Gemini_Generated_Image_uyxy5suyxy5suyxy

Self-Hosting 2FAuth: Never Lose Your 2FA Codes Again

I recently went through the frustrating experience of switching phones and discovering that all my Google Authenticator codes had vanished. No backup, no export, just gone. If you’ve been through this, you know the panic. It sent me down a rabbit hole looking for a better solution — one that wouldn’t leave me stranded every time I changed devices.

The result is a self-hosted 2FA setup using 2FAuth, a lightweight open-source web app for managing two-factor authentication codes. Here’s how I set it up and why I think it’s the right approach for anyone running a homelab.

Why Not Just Use Google Authenticator?

Google Authenticator has improved over the years and does support Google account sync now, but it’s still a black box. You’re trusting Google with your 2FA secrets, the export/import story is clunky, and if something goes wrong during a phone switch you’re in trouble. I wanted something I owned and controlled.

My requirements were simple:

  • Open source
  • Self-hosted — my data, my server
  • Cloud sync so a broken phone doesn’t lock me out of everything
  • A proper mobile app that communicates via API, not just a browser wrapper
  • Offline support — codes should work even when away from home

2FAuth ticks every one of those boxes.

What Is 2FAuth?

2FAuth is a self-hosted web application for managing TOTP and HOTP two-factor authentication accounts. It stores your 2FA secrets on your own server in a SQLite database, provides a clean web UI, and exposes a REST API that third-party apps can use to sync and generate codes.

For Android there’s a companion app — 2FAuth for Android — that connects to your self-hosted instance via API token, caches all your accounts locally in an encrypted vault, and generates codes even when your server isn’t reachable. It’s not on the Play Store yet but is available as a sideloadable APK from the GitHub releases page.

The Stack

I run everything on a Proxmox homelab with a dedicated Docker LXC managed by Dockge. The 2FAuth setup is a single container with a SQLite database — no Postgres, no Redis, no extra services to manage.

Setting It Up

1. Create the stack directory

mkdir -p /opt/stacks/2fauth/data
chown -R 1000:1000 /opt/stacks/2fauth/data

The chown is important — the container runs as UID 1000 and needs write access to the data directory.

2. Compose file

In Dockge, create a new stack called 2fauth with the following:

services:
  2fauth:
    image: 2fauth/2fauth
    container_name: 2fauth
    restart: unless-stopped
    ports:
      - 8082:8000
    volumes:
      - ./data:/2fauth
    environment:
      - APP_NAME=2FAuth
      - APP_ENV=local
      - APP_DEBUG=false
      - [email protected]
      - APP_URL=https://2fa.yourdomain.com
      - APP_KEY=
      - DB_CONNECTION=sqlite
      - CACHE_DRIVER=file
      - SESSION_DRIVER=file
networks: {}

Leave APP_KEY blank on first deploy — 2FAuth generates one automatically. After first boot, grab the generated key and add it to your compose so it persists across container recreations:

docker exec 2fauth php artisan key:generate --show

Copy the output and set it as APP_KEY in your compose, then redeploy.

3. Reverse proxy

I use NPMPlus (nginx Proxy Manager Plus) with Cloudflare for SSL. Add a proxy host pointing 2fa.yourdomain.com at your Docker host on port 8082, enable SSL, done.

4. Create your account

Open https://2fa.yourdomain.com in a browser and click Register to create the first user account. Once registered, go to Settings → Administration and disable open registration so no one else can sign up.

5. Add SMTP for email notifications (optional)

2FAuth can send login notification emails. Add your SMTP details to the environment block:

- MAIL_MAILER=smtp
- MAIL_HOST=mail.yourdomain.com
- MAIL_PORT=587
- [email protected]
- MAIL_PASSWORD=yourpassword
- MAIL_ENCRYPTION=tls
- [email protected]
- MAIL_FROM_NAME=2FAuth

Setting Up the Android App

The 2FAuth for Android app isn’t on the Play Store yet, so you’ll need to sideload it:

  1. Download the latest APK from the GitHub releases page
  2. On your Android device, go to Settings → Apps → Special app access → Install unknown apps and allow your browser to install APKs
  3. Open the downloaded APK and install it

To connect the app to your server:

  1. In the 2FAuth web UI, go to Settings → Personal Access Tokens and generate a new token
  2. Open the Android app and add a new account/server
  3. Enter your server URL (https://2fa.yourdomain.com) and paste the API token

The app will sync all your 2FA accounts from the server, store them locally in an AES-256-GCM encrypted vault, and generate codes even when you’re not connected to your server. You can unlock the vault with a PIN or biometrics.

The Key Benefit: Phone Switches Are No Longer a Problem

This is the whole point. When you get a new phone:

  1. Install the APK
  2. Point it at your server
  3. Paste your API token
  4. Done — all your codes are back

Your 2FA secrets live on your server, not on any individual device. The devices are just clients.

A Note on Security

Putting your 2FA server on the internet does expose a login page. A few ways to harden this:

  • Cloudflare Access — put the domain behind Cloudflare Access so there’s an additional identity check before anyone reaches the 2FAuth login page. Free tier covers this.
  • Strong password + disable registration — at minimum, use a strong unique password and turn off open registration immediately after setup.
  • VPN only — don’t expose it publicly at all. The Android app works offline anyway, so you only need server connectivity when syncing new accounts.

Note that the Android app connects via API token, not through the web login page — so day-to-day use doesn’t touch the login page at all.

Final Thoughts

2FAuth is exactly what I was looking for — simple, self-hosted, open source, and genuinely useful. The Android app’s offline-first approach means I get the convenience of local code generation with the safety net of server-side backup. No more losing all my 2FA codes when I change phones.

If you’re running a homelab and rely on two-factor authentication, this setup is worth the hour it takes to get running.


2FAuth: github.com/Bubka/2FAuth
2FAuth for Android: github.com/ryosoftware/2fauth-for-android

874c482b-17cb-4c23-9011-9e94b379e367

Ditch the App Password: WordPress + Microsoft 365 Email Done Right

Background

I recently set up a WordPress site for a small business that uses Microsoft 365 for email. The obvious first attempt was to use WP Mail SMTP with basic SMTP auth — set the host to smtp.office365.com, port 587, STARTTLS, drop in an app password, and call it done. That didn’t work.

The SMTP debug log told the story clearly:

535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policy.

Microsoft 365 tenants have Security Defaults enabled by default, which blocks basic/legacy authentication — including SMTP AUTH with app passwords — across the whole tenant. Even after disabling Security Defaults and enabling per-mailbox SMTP AUTH, the propagation delay and Microsoft’s ongoing deprecation of basic auth makes this an unreliable path. OAuth 2.0 is the right solution.


What you’ll need

  • A WordPress site
  • A Microsoft 365 account with a licensed mailbox
  • An admin account on the Microsoft 365 tenant (Global Administrator role)
  • Access to the Microsoft Entra admin centre

In my case the business had a licensed user mailbox for day-to-day email and a shared mailbox for general enquiries (e.g. [email protected]). The goal was to send WordPress emails from the shared mailbox. More on how that works below.


Step 1 — Install FluentSMTP

FluentSMTP is a free, open-source WordPress plugin that supports Microsoft 365 OAuth 2.0 at no cost — unlike WP Mail SMTP and Post SMTP, which gate the Microsoft 365 OAuth option behind a paid plan.

Install it from the WordPress plugin directory:

  1. Go to Plugins → Add New
  2. Search for FluentSMTP
  3. Install and activate
  4. Go to Settings → FluentSMTP
  5. Select Microsoft as your email provider

Before doing anything else, copy the App Callback URL shown on the settings page — you’ll need it in the next step. Leave this tab open.


Step 2 — Register an app in Microsoft Entra

FluentSMTP authenticates via an Azure app registration. You need to create one in the Microsoft Entra admin centre.

  1. Go to entra.microsoft.com and sign in with your admin account
  2. Navigate to Identity → Applications → App registrations
  3. Click + New registration
  4. Fill in the form:
    • Name: anything descriptive, e.g. WordPress Mail
    • Supported account types: select “Accounts in any organizational directory (Any Azure AD directory – Multitenant) and personal Microsoft accounts” — this is required by FluentSMTP
    • Redirect URI: set the dropdown to Web and paste the App Callback URL from FluentSMTP
  5. Click Register
  6. On the overview page, copy the Application (client) ID

⚠️ Pitfall: wrong account type

If you select single-tenant instead of multitenant, the OAuth redirect will fail with AADSTS50194: Application is not configured as a multi-tenant application and the access token box in FluentSMTP will come back empty. If this happens, go to Authentication in your app registration and change the supported account types, then try again.


Step 3 — Create a client secret

  1. In your app registration, click Certificates & secrets in the left sidebar
  2. Click + New client secret
  3. Give it a description and set expiry to 24 months
  4. Click Add
  5. Copy the Value immediately — it is only shown once and will be masked on your next visit

⚠️ Pitfall: secret expiry

The client secret will expire after 24 months and WordPress emails will silently stop sending. Set a calendar reminder for around 22 months from now to come back and renew it under Certificates & secrets.


Step 4 — Add API permissions

The app needs explicit Microsoft Graph permissions to send mail.

  1. In your app registration, click API permissions
  2. Click + Add a permission → Microsoft Graph → Delegated permissions
  3. Search for and tick each of the following:
    • Mail.Send
    • Mail.Send.Shared (needed if sending from a shared mailbox)
    • offline_access (needed for token refresh)
  4. Click Add permissions
  5. Click Grant admin consent for [your organisation] and confirm

All permissions should show a green Granted status in the configured permissions list.


Step 5 — Configure FluentSMTP and authenticate

  1. Go back to Settings → FluentSMTP in WordPress
  2. Fill in:
    • Sender Name: your business name
    • Sender Email: the address emails should come from
    • Application Client ID: the Application ID from Step 2
    • Application Client Secret: the Value from Step 3
  3. Click Authenticate with Office 365 & Get Access Token

A Microsoft login popup will appear. A few important things here:

  • Sign in with an account that has Global Administrator rights on the tenant
  • On the consent screen, tick “Consent on behalf of your organization” before clicking Accept — if you skip this, other users on the tenant won’t be covered
  • Make sure you are doing this in the same browser profile that is logged into Entra — if WordPress is open in one profile and Entra in another, it will authenticate the wrong account

After accepting, you’ll be redirected back to a page showing your access token. Copy it, paste it into the Access Token field in FluentSMTP, and click Save Connection Settings.


A note on shared mailboxes

If you want WordPress to send from a shared mailbox (e.g. [email protected]) rather than a licensed user mailbox, this is fully supported — but the OAuth authentication still happens via a licensed user account. You cannot authenticate directly as a shared mailbox since it has no password or OAuth credentials of its own.

The correct approach is:

Microsoft 365 will honour the shared mailbox as the from address as long as the licensed user has Send As permissions on the shared mailbox. You can verify this in the Microsoft 365 admin centre under Teams & groups → Shared mailboxes → [your mailbox] → Send As permissions. This is also why you need Mail.Send.Shared in your API permissions.


Step 6 — Test it

  1. Go to the Email Test tab in FluentSMTP
  2. Set From to your sender address
  3. Set Send To to an address you can check
  4. Click Send Test Email

If it goes through, you’re done. FluentSMTP hooks into WordPress’s core wp_mail() function, which means every plugin that sends email through WordPress — WPForms, WooCommerce, comment notifications, password resets — will automatically use this setup without any additional configuration.


Troubleshooting summary

ErrorCauseFix
535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policySecurity Defaults enabled on tenantDisable Security Defaults in Entra under Identity → Overview → Properties
AADSTS50194 — empty access token boxApp registered as single-tenantChange supported account types to Multitenant in Authentication settings
Need admin approval screenUser account is not a Global AdminClick “Have an admin account?” and sign in with an admin account
Not Found on test emailMissing API permissionsAdd Mail.Send, Mail.Send.Shared, offline_access and grant admin consent
Forbidden on test emailWrong account authenticated or consent not granted for organisationRe-authenticate, ensure same browser profile, tick “Consent on behalf of your organization”

Once it’s working, WordPress email is one less thing to worry about. The OAuth token refreshes automatically via the offline_access permission — the only maintenance required is renewing the client secret every 24 months.

Gemini_Generated_Image_1omwip1omwip1omw

Migrating from Nginx Proxy Manager to NPMPlus with CrowdSec: A Complete Walkthrough

I replaced my standard Nginx Proxy Manager instance with NPMPlus (an enhanced fork) and integrated CrowdSec for automated threat detection and blocking — including Cloudflare Turnstile captcha challenges. The whole stack runs in Docker, managed via Dockge, and sits behind itself as a reverse proxy. Here’s exactly how I did it, including the gotchas I hit along the way

Screenshot_20260216_022334

Converting an Old NTFS Drive to ext4 on Arch Linux (The “Nuke and Pave” Method)

A practical, step-by-step guide on wiping a Windows NTFS hard drive and preparing it for native Arch Linux use. The post walks you through using cfdisk to recreate the partition table, forcing a format with mkfs.ext4 to overwrite stubborn NTFS signatures, configuring auto-mounting via /etc/fstab, and resolving the common ext4 root-ownership permission block so that the drive is fully usable by your user account

unnamed

Switching from Windows 11 to CachyOS Linux

After growing tired of Microsoft’s aggressive pop-ups and forced features, the author shares their experience migrating their primary AMD gaming rig (Ryzen 7 7700X, Radeon 7900 GRE) from Windows 11 to CachyOS, an Arch-based Linux distribution known for speed and performance. The post details the smooth gaming experience (easily hitting 165 FPS in EVE Online out of the box), adapting to KDE Plasma and package managers like Flatpak, and a clever workaround using a Proxmox-hosted Windows 10 VM via Remmina for their daily work needs. Ultimately, the author highly recommends the switch for enthusiasts looking to take back control of their hardware.