DEV Community: Zia Ullah

How to Deploy a Full-Stack Node.js App on Azure: A Step-by-Step Guide

Zia Ullah — Sat, 13 Jun 2026 23:32:59 +0000

The first time I deployed a production app to Azure, I spent three hours troubleshooting a crash that turned out to be one line: the app was listening on port 3000 instead of process.env.PORT. Azure injects its own port at runtime, and if your app ignores it, the health check fails silently and the whole thing dies on startup.

That was my introduction to cloud deployment. Since then I've deployed several production apps to Azure across different projects. I've made most of the mistakes worth making, and this guide is the walkthrough I wish I'd had.

We'll cover App Service, Azure Database for PostgreSQL, environment variables, and a GitHub Actions CI/CD pipeline that handles deployments automatically.

Prerequisites

An Azure account (free tier works for this guide)
A Node.js app (Express or similar) with a package.json
PostgreSQL as your database
A GitHub repository for your code
Azure CLI installed locally

What We'll Deploy

Backend: Node.js / Express API
Database: Azure Database for PostgreSQL (Flexible Server)
Hosting: Azure App Service (Linux)
CI/CD: GitHub Actions

Step 1: Create a Resource Group

Everything in Azure lives inside a Resource Group — a logical container for all your app's cloud resources.

az login

az group create \
  --name myapp-rg \
  --location westeurope

Use a location close to your users. westeurope (Netherlands) works well for European users.

Step 2: Create the PostgreSQL Database

Today, the recommended option is Azure Database for PostgreSQL Flexible Server. It is cheaper and more flexible than the older Single Server from Azure, which is being retired.

az postgres flexible-server create \
  --resource-group myapp-rg \
  --name myapp-db-server \
  --location westeurope \
  --admin-user dbadmin \
  --admin-password YourStrongPassword123! \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --storage-size 32 \
  --version 15

Then create your database:

az postgres flexible-server db create \
  --resource-group myapp-rg \
  --server-name myapp-db-server \
  --database-name myappdb

Allow your App Service to connect by adding a firewall rule:

az postgres flexible-server firewall-rule create \
  --resource-group myapp-rg \
  --name myapp-db-server \
  --rule-name AllowAzureServices \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0

Setting start and end IP to 0.0.0.0 allows Azure-internal traffic. This is fine for App Service to Database communication — just don't open it to public internet IPs.

Step 3: Create the App Service Plan and Web App

The compute resources are defined by the App Service Plan. Begin at B1 (Basic) and develop later if required.

az appservice plan create \
  --name myapp-plan \
  --resource-group myapp-rg \
  --sku B1 \
  --is-linux

az webapp create \
  --name myapp-api \
  --resource-group myapp-rg \
  --plan myapp-plan \
  --runtime "NODE:20-lts"

Your app will be live at: https://myapp-api.azurewebsites.net

Step 4: Set Environment Variables

Never put secrets in your code. Azure App Service has Application Settings. They are injected as environment variables on runtime, never touching your source code or repository.

az webapp config appsettings set \
  --name myapp-api \
  --resource-group myapp-rg \
  --settings \
    NODE_ENV=production \
    DATABASE_URL="postgresql://dbadmin:YourStrongPassword123!@myapp-db-server.postgres.database.azure.com/myappdb?sslmode=require" \
    JWT_SECRET="your-secret-key-here" \
    PORT=8080

In your Node.js app, read them as normal:

const dbUrl = process.env.DATABASE_URL;
const jwtSecret = process.env.JWT_SECRET;

And this is the fix for the port issue I mentioned at the start — make sure your server uses process.env.PORT:

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => console.log(`Running on port ${PORT}`));

Step 5: Prepare Your App for Production

Make sure your package.json has a start script:

{
  "scripts": {
    "start": "node server.js",
    "build": "npm install --production"
  }
}

Azure PostgreSQL requires SSL. If you're using the pg package:

const { Pool } = require('pg');

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: {
    rejectUnauthorized: false,
  },
});

Pin your Node.js version in package.json:

{
  "engines": {
    "node": ">=20.0.0"
  }
}

Step 6: Deploy with GitHub Actions (CI/CD)

Manual deployments are OK, but once you have GitHub Actions set up, every push to main automatically deploys. The azure documentation for this is not great so here is the exact process:

Get your publish profile:

az webapp deployment list-publishing-profiles \
  --name myapp-api \
  --resource-group myapp-rg \
  --xml

Copy the XML output. In your GitHub repo go to Settings → Secrets → Actions and add a secret called AZURE_WEBAPP_PUBLISH_PROFILE with that XML as the value.

Then create .github/workflows/deploy.yml:

name: Deploy to Azure

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci --production

      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: myapp-api
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: .

Push to main, watch the Actions tab, and your app is live within a couple of minutes.

Step 7: Run Database Migrations on Deploy

If you use a migration tool like Knex or db-migrate, add a migration step before deploying:

- name: Run database migrations
  run: npm run migrate
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

Add DATABASE_URL as a separate GitHub Actions secret for this.

Step 8: Set Up Health Checks

Add a health endpoint to your app:

app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok', timestamp: new Date().toISOString() });
});

Configure Azure to use it:

az webapp config set \
  --name myapp-api \
  --resource-group myapp-rg \
  --generic-configurations '{"healthCheckPath": "/health"}'

Azure periodically pings this endpoint. If it gets anything other than 200, it takes traffic off that instance and starts it back up again. It's saved me a few times when a deployment went awry.

Monitoring and Logs

To stream live logs:

az webapp log tail \
  --name myapp-api \
  --resource-group myapp-rg

For Application Insights, initialize the SDK at the very top of your entry file, before any other imports:

const appInsights = require('applicationinsights');
appInsights.setup(process.env.APPLICATIONINSIGHTS_CONNECTION_STRING).start();

Things That Caught Me Off Guard

A few things from running Node.js apps on Azure in production that aren't obvious from the docs.

Turn on "Always On" under Configuration → General Settings. By default, Azure puts your app to sleep after a period of inactivity on lower tiers. If you're building anything where users expect instant response — not a 15-second cold start — you need this on. I've seen clients blame "the server" for slowness when it was just Azure waking up from idle.

Use deployment slots. Azure App Service lets you deploy to a staging slot first, verify everything works, then swap to production with zero downtime. The swap is quick and reversible. I started using this after a bad deployment took down a production app during business hours. It won't happen again.

Watch your PostgreSQL CPU credits on the Burstable tier. The B1ms is cheap but runs on burstable CPU — you have a credit bucket that depletes under sustained load. Set up an Azure Monitor alert on CPU credit balance so you know before the instance starts throttling, not after users start complaining.

Wrapping Up

From the first az login to a live URL takes about 30 minutes. After that, the GitHub Actions pipeline handles every deployment automatically. Migrations run on push, and health checks restart the app if anything goes wrong.

The things that trip up most people are the PORT variable, SSL on the PostgreSQL connection, and forgetting to turn on Always On. Get these right from the start, and you'll save yourself a few hours of debugging.

Zia Ullah is a full-stack developer with over 12 years of experience, starting in 2013. He specializes in web applications for healthcare and SaaS. He works at ValueAdd, a software development company based in Sweden.

How to Build a Secure Audit Trail in Your Web App (No Third-Party Tools)

Zia Ullah — Sat, 13 Jun 2026 22:48:18 +0000

How to Build a Secure Audit Trail in Your Web App (No Third-Party Tools)
I never cared for audit trails too much until we did our first compliance review on a healthcare project I was working on. The first question asked of the auditor was:

Please provide me with everything you did to this record in the last 90 days.

We could not. Not properly, anyway.

At that point, I made logging not an afterthought. When you are building anything that involves some sensitive data, your builds could be in healthcare, or maybe finance, or perhaps internal admin tools — you need a real audit trail. Not some console. queryable, a tamper-resistant log of who did what and when —log wrapper.
Here is a tutorial on how to build your own from scratch using Node.js, Express, and PostgreSQL. No third-party service is needed.

Prerequisites

Node.js (v18+)
PostgreSQL (v14+)
Basics of SQL and Express
pg npm package for Database Access Management

What Is an Audit Trail?

An audit trail is a record of all important events that have taken place in your system in an append-only style. The magic word is append-only — rows are appended, rows can never change or be deleted. That’s what makes it reliable.
When something goes wrong — a record gets changed, data goes missing, a user complains their information was modified — you want to be able to pull up a timeline and say exactly what happened. Without a proper audit trail, you're guessing.
The things you need to capture per action: who did it, what they did, which record was affected, when it happened, what changed (before and after), and where the request came from (IP, device).

Step 1: Design the Audit Log Table

The audit log lives in its own table and should be treated as write-only.

CREATE TABLE audit_logs (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id       UUID NOT NULL,
  user_email    TEXT NOT NULL,
  action        TEXT NOT NULL,          -- 'CREATE', 'UPDATE', 'DELETE', 'VIEW'
  resource      TEXT NOT NULL,          -- table or resource name, e.g. 'medications'
  resource_id   TEXT,                   -- the affected record's ID
  old_values    JSONB,                  -- snapshot before change
  new_values    JSONB,                  -- snapshot after change
  ip_address    INET,
  user_agent    TEXT,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Index for fast lookups by user or resource
CREATE INDEX idx_audit_user_id ON audit_logs(user_id);
CREATE INDEX idx_audit_resource ON audit_logs(resource, resource_id);
CREATE INDEX idx_audit_created_at ON audit_logs(created_at DESC);

A few things worth noting about the design. JSONB for old/new values means you don't have to run a migration every time your data model changes — the log just captures whatever shape the record had at that point in time. TIMESTAMPTZ instead of TIMESTAMP is important if your users are in different time zones. And there's no updated_at column here — audit logs don't get updated.

Step 2: Create an Audit Service

Consolidate audit logging in a single service to make it consistent and easy to call from anywhere.

// services/auditService.js
const { pool } = require('../db');

async function log({
  userId,
  userEmail,
  action,
  resource,
  resourceId = null,
  oldValues = null,
  newValues = null,
  ipAddress = null,
  userAgent = null,
}) {
  const query = `
    INSERT INTO audit_logs
      (user_id, user_email, action, resource, resource_id, old_values, new_values, ip_address, user_agent)
    VALUES
      ($1, $2, $3, $4, $5, $6, $7, $8, $9)
  `;

  const values = [
    userId,
    userEmail,
    action,
    resource,
    resourceId,
    oldValues ? JSON.stringify(oldValues) : null,
    newValues ? JSON.stringify(newValues) : null,
    ipAddress,
    userAgent,
  ];

  // Don't await — fire-and-forget to avoid blocking the main request
  pool.query(query, values).catch((err) => {
    console.error('[AuditService] Failed to write audit log:', err.message);
  });
}

module.exports = { log };

Look at pool.query is called without await. This is by design; audit logging should never cause a user-facing request to fail or slow down. I learned this the hard way when a slow database insert blocked a critical record update in production. It was easily fixed. Fire and forget. Catch errors silently and move on.

Step 3: Add It to Your Routes

Here's a real example — updating a sensitive record:

const express = require('express');
const router = express.Router();
const audit = require('../services/auditService');
const { getRecordById, updateRecord } = require('../models/record');

router.put('/:id', async (req, res) => {
  const { id } = req.params;
  const userId = req.user.id;
  const userEmail = req.user.email;

  try {
    // Fetch the current state before updating
    const oldRecord = await getRecordById(id);

    // Perform the update
    const updated = await updateRecord(id, req.body);

    // Log the change
    audit.log({
      userId,
      userEmail,
      action: 'UPDATE',
      resource: 'records',
      resourceId: id,
      oldValues: oldRecord,
      newValues: updated,
      ipAddress: req.ip,
      userAgent: req.headers['user-agent'],
    });

    res.json(updated);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

Always capture oldValues before changing them. Once you take the record away, it’s gone.

Step 4: Build an Express Middleware for Read Logging

For sensitive resources, you may want to log even read (VIEW) actions. Use middleware so you don't have to add it to every route manually.

// middleware/auditRead.js
const audit = require('../services/auditService');

function auditRead(resource) {
  return (req, res, next) => {
    if (req.user) {
      audit.log({
        userId: req.user.id,
        userEmail: req.user.email,
        action: 'VIEW',
        resource,
        resourceId: req.params.id || null,
        ipAddress: req.ip,
        userAgent: req.headers['user-agent'],
      });
    }
    next();
  };
}

module.exports = auditRead;

Apply it to any route:

const auditRead = require('../middleware/auditRead');
router.get('/:id', auditRead('records'), async (req, res) => {
  // your handler
});

Step 5: Query the Audit Log

Give your admins a way to read the log. Here's a simple API endpoint with filtering:

router.get('/', async (req, res) => {
  const { userId, resource, from, to, limit = 100 } = req.query;

  let query = 'SELECT * FROM audit_logs WHERE 1=1';
  const params = [];

  if (userId) {
    params.push(userId);
    query += ` AND user_id = $${params.length}`;
  }
  if (resource) {
    params.push(resource);
    query += ` AND resource = $${params.length}`;
  }
  if (from) {
    params.push(from);
    query += ` AND created_at >= $${params.length}`;
  }
  if (to) {
    params.push(to);
    query += ` AND created_at <= $${params.length}`;
  }

  params.push(Math.min(parseInt(limit), 500));
  query += ` ORDER BY created_at DESC LIMIT $${params.length}`;

  const result = await pool.query(query, params);
  res.json(result.rows);
});

Cap the limit (here at 500) to prevent someone from accidentally dumping the entire log in one request.

Step 6: Protect the Audit Log

The audit table is only useful if nobody can tamper with it. Enforce this at the database level:

REVOKE DELETE, UPDATE ON audit_logs FROM app_user;

Beyond that, only admins and compliance roles should be able to query the log. Consider a separate database user for writing vs. reading: your API uses audit_writer (INSERT only), your admin dashboard uses audit_reader (SELECT only). A compromised API key cannot read the audit history, even if it tries.

Handling Bulk Operations

When a single action affects multiple records, create one audit entry per record — not one entry for the entire batch. This makes it possible to trace the history of any individual record without parsing bulk entries.

for (const record of affectedRecords) {
  audit.log({
    userId,
    userEmail,
    action: 'DELETE',
    resource: 'items',
    resourceId: record.id,
    oldValues: record,
    ipAddress: req.ip,
    userAgent: req.headers['user-agent'],
  });
}

Things I'd Do Differently

Working on compliance-sensitive projects has taught me a few things about audit logging that I wish I'd known earlier.
The biggest one: log the reason, not just the action. For high-risk operations like deletions or adjustments, add a reason field. When a discrepancy comes up months later, "disposal — patient refused" is infinitely more useful than just seeing a number change in the data. A plain UPDATE tells you nothing about why.
Second: store the user's role at log time. Roles change. If someone was an admin when they made a change and you only stored their user ID, you'll have to reconstruct what role they had at that point in time — usually when you're already under pressure. Just log role: 'admin' alongside the user ID.
And build the query UI early. The first few months on one project we had the data but no easy way to search it, which meant every incident investigation started with someone running raw SQL. A simple admin page with date range and user filters makes a huge difference when you actually need it.

Wrapping Up

The core pattern is simple: append-only table, a central log function that never blocks, and database-level protection against tampering. Most of the complexity is in the details — what to log, how to query it, and how to make it useful when you actually need it.
Get the foundation in place early. It's much harder to retrofit an audit trail into an existing app than to build it in from the start.

Zia Ullah is a full-stack developer with 12+ years of experience (since 2013), specializing in web applications for healthcare and SaaS. He works at ValueAdd, a software development company based in Sweden.