DEV Community: Harsh Gupta

How to Configure keyVaultReferenceIdentity in Azure App Service?

Harsh Gupta — Sat, 25 Jul 2026 00:00:47 +0000

Overview

This guide shows you how to fix a critical Azure App Service configuration issue where the keyVaultReferenceIdentity property is hidden from the Azure Portal but required for accessing Key Vault secrets.

Symptoms

Developers encountering this issue typically observe:

Key Vault references returning empty values instead of secret content
Configuration entries showing "Not Resolved" error messages
Application settings failing to fetch secret values from Key Vault
Authentication errors when attempting to access protected secrets
401/403 errors from App Service attempting to validate Key Vault access

Why This Happens

Azure App Service uses Managed Identity authentication to access Key Vault secrets, but the keyVaultReferenceIdentity property is deliberately hidden from standard Azure Portal interfaces. This property only exists at the Azure Resource Manager (ARM) level, making it invisible through the typical Azure management UI.

Technical Architecture

App Service → Managed Identity → Azure AD → Key Vault Access Policy → Secret Store

App Service attempts to authenticate using its assigned Managed Identity
Azure needs explicit permission through the keyVaultReferenceIdentity property
This permission exists only in the underlying ARM configuration
Without this configuration, the authentication chain breaks
Key Vault references resolve to empty values or error messages

Why Portal Visibility is Limited

Microsoft implements this design choice for several reasons:

Security: Keeps identity-to-Key Vault mappings out of standard management interfaces
Simplicity: Prevents accidental misconfigurations that could cause security issues
Audit Trail: Ensures all identity configurations go through proper change management
Resource Provider: Some properties require ARM-level configuration for consistency

Prerequisites

Required Azure Resources

Azure Subscription: Active subscription with appropriate permissions
Azure App Service: Existing Linux or Windows App Service
User-Assigned Managed Identity: Pre-created Managed Identity for the App Service
Azure Key Vault: Key Vault with access policies configured for the Managed Identity

Required Tools and Permissions

Azure CLI: Version 2.0+ installed locally
PowerShell: Azure Az module installed
RBAC Permissions:

Contributor or Owner role on App Service resource
Reader role minimum for resource listing
Key Vault access policies granting Get Secret permissions

Environment Setup

# Install required Azure CLI extensions
az extension add --name keyvault

# Verify Azure CLI installation
az --version

# Login to Azure (if not already authenticated)
az login

Step-by-Step Solution Guide

Step 1: Prepare Your PowerShell Environment

Initialize your PowerShell session and clear any cached authentication tokens:

# Connect to Azure (if not already connected)
Connect-AzAccount

# Clear any cached authentication tokens
Clear-AzTokenCache

# Verify current authentication status
Get-AzContext

Step 2: Target the Correct Azure Subscription

Set the correct subscription context for your infrastructure:

# List all accessible subscriptions
Get-AzSubscription | Select-Object Name, Id, State

# Set your target subscription
Set-AzContext -SubscriptionId "YOUR-SUBSCRIPTION-ID"

Step 3: Execute the ARM Fix Script

Apply the required KeyVault Reference Identity configuration:

# =========================================================================
# FIX: App Service KeyVault Reference Identity Configuration Script
# =========================================================================

# 1. Configure your deployment variables
$subscriptionId = "YOUR-SUBSCRIPTION-ID"
$resourceGroup  = "your-resource-group-name"
$identityName   = "your-managed-identity-name"
$appName        = "your-app-service-name"

# 2. Construct the User-Assigned Identity Resource URL
$identityUrl = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/$identityName"

# 3. Retrieve the App Service's resource ID
$appUrl = Get-AzWebApp -ResourceGroupName $resourceGroup -Name $appName | Select-Object -ExpandProperty Id

# 4. Prepare the ARM PATCH request payload
$uriPath = "{0}?api-version=2021-01-01" -f $appUrl
$payload = @{
    properties = @{
        keyVaultReferenceIdentity = $identityUrl
    }
} | ConvertTo-Json -Depth 3

# 5. Execute the API update request
$response = Invoke-AzRestMethod -Method PATCH -Path $uriPath -Payload $payload

# 6. Verify successful execution
$response.Content | ConvertFrom-Json

Step 4: Complete Verification Process

After script execution, complete these validation steps:

Restart App Service

Azure Portal: Navigate to App Service → Overview → Restart button
PowerShell: Restart-AzWebApp -ResourceGroupName $resourceGroup -Name $appName
Purpose: Force reload of new identity configuration

Validate Application Settings

Access your App Service in Azure Portal
Navigate to Settings → Configuration → Application Settings
Locate Key Vault reference entries
Confirm green checkmarks (✅) indicate successful resolution
Verify secrets display values like @Microsoft.KeyVault(VaultName={your-key-vault-name},SecretName={your-secret-name})

Test Secret Access

Check application logs for resolution status
Verify actual secret values are accessible
Confirm application functionality with Key Vault integration

Success Checklist

User-Assigned Managed Identity assigned to App Service
PowerShell script executed without errors
App Service restarted successfully
Green checkmarks visible in Application Settings
Secret values properly resolved
Application functions normally

Common Issues and Troubleshooting

Issue: "Not Resolved" Errors Persist

Root Cause: User-Assigned Managed Identity not attached to App Service

Solution: Verify identity assignment in Azure Portal:

Open your App Service in Azure Portal
Navigate to Identity → User assigned → Assigned identities
Confirm your Managed Identity is listed and enabled

Issue: Permission Denied

Root Cause: Insufficient RBAC permissions

Solution: Grant required permissions:

Navigate to your App Service → Access control (IAM)
Add Contributor role for comprehensive permissions
Alternative: Grant specific Microsoft.Web/sites/write permission

Issue: Cross-Subscription Access

Root Cause: Key Vault, Managed Identity, and App Service in different subscriptions

Solution: Ensure all resources in same subscription:

Deploy all resources to identical subscription
Verify Key Vault access policies allow Managed Identity from current subscription
Use cross-tenant access if working across subscriptions

Security Considerations

Required RBAC Permissions

The script requires these specific Azure permissions:

Permission	Required For	Description
Microsoft.Web/sites/read	Get-AzWebApp	Read App Service properties
Microsoft.Web/sites/write	PATCH operation	Update App Service configuration
Microsoft.ManagedIdentity/userAssignedIdentities/read	Identity reference	Read Managed Identity details

Security Best Practices

Principle of Least Privilege: Use Contributor role instead of Owner when possible
Identity Lifecycle Management: Regularly review and rotate Managed Identity access
Audit Compliance: Enable diagnostic settings for tracking configuration changes
Access Policy Configuration: Configure Key Vault access policies with specific permissions
Secret Rotation: Implement automated Key Vault secret rotation policies

Alternative Implementation Methods

Azure CLI Solution

az webapp update --resource-group your-resource-group \
  --name your-app-name \
  --set properties.keyVaultReferenceIdentity="/subscriptions/YOUR-SUBSCRIPTION-ID/resourceGroups/your-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/your-identity-name"

# Verify the update
az webapp show --resource-group your-resource-group --name your-app-name --query properties.keyVaultReferenceIdentity

Infrastructure as Code (Bicep)

@description('App Service name')
param appServiceName string

@description('Resource group name')
param resourceGroupName string

@description('Location for all resources')
param location string

@description('User-Assigned Managed Identity ID')
param keyVaultReferenceIdentityId string

resource appService 'Microsoft.Web/sites@2021-01-01' = {
  name: appServiceName
  location: location
  resourceGroupName: resourceGroupName
  kind: 'linux'
  properties: {
    serverFarmId: appServicePlanId
    keyVaultReferenceIdentity: keyVaultReferenceIdentityId
  }
}

Infrastructure as Code (Terraform)

resource "azurerm_app_service" "example" {
  name                = "your-app-name"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  app_service_plan_id = azurerm_app_service_plan.example.id
  kind                = "linux"

  site_config {
    min_tls_version = "1.2"
  }

  identity {
    type         = "UserAssigned"
    identity_ids = [azurerm_user_assigned_identity.example.id]
  }

  lifecycle {
    ignore_changes = all
  }
}

resource "azurerm_key_vault" "example" {
  name                     = "your-keyvault-name"
  location                 = azurerm_resource_group.example.location
  resource_group_name      = azurerm_resource_group.example.name
  tenant_id               = data.azurerm_client_config.current.tenant_id
  sku_name                 = "standard"
  enabled_for_template_deployment = true

  access_policy {
    tenant_id = azurerm_app_service.example.identity.0.tenant_id
    object_id = azurerm_app_service.example.identity.0.principal_id
    secret_permissions = ["get", "list"]
  }
}

Technical Limitations and Considerations

Current Limitations

Portal Invisibility: The keyVaultReferenceIdentity property cannot be managed through Azure Portal
API Version Dependency: Uses ARM API version 2021-01-01
Resource Provider Constraints: Requires Microsoft.Web/sites resource provider availability
Manual Configuration: Requires PowerShell or CLI interaction for setup

Performance Impact

App Service Restart: Required for configuration changes to take effect
Authentication Overhead: Additional identity validation adds minimal latency
Resource Consumption: No significant performance impact on secret retrieval

Common Implementation Mistakes

Mistake 1: Premature Script Execution

Problem: Running configuration script before identity assignment
Solution: Always assign Managed Identity first, then execute PowerShell script

Mistake 2: Incorrect Subscription Context

Problem: Script running in wrong Azure subscription
Solution: Verify subscription context with Get-AzContext before running

Mistake 3: Incomplete Identity URLs

Problem: Missing subscription ID or resource group in identity URL
Solution: Ensure complete resource URL construction in script

SEO Optimization Keywords

Azure App Service KeyVault Reference Identity
Azure Key Vault access with App Service
Azure Managed Identity for App Service
Azure Key Vault references configuration
Azure App Service secret management
Azure KeyVault integration with App Service
Azure Resource Manager ARM configuration
Azure App Service Key Vault fix
Azure Web Apps KeyVault identity
Azure App Service Managed Identity configuration

Quick Reference Commands

PowerShell Commands

# Check current subscription context
Get-AzContext

# List all available subscriptions
Get-AzSubscription | Select-Object Name, Id, State

# Set subscription context
Set-AzContext -SubscriptionId "your-subscription-id"

# Retrieve App Service information
Get-AzWebApp -ResourceGroupName "your-rg" -Name "your-app-name"

# Restart App Service to apply changes
Restart-AzWebApp -ResourceGroupName "your-rg" -Name "your-app-name"

# Get diagnostic logs
Get-AzWebAppLog -ResourceGroupName "your-rg" -Name "your-app-name"

Verification Commands

# Verify KeyVaultReferenceIdentity configuration
Get-AzWebApp -ResourceGroupName "your-rg" -Name "your-app-name" | Select-Object -ExpandProperty KeyVaultReferenceIdentity

# Check App Service identity status
Get-AzWebApp -ResourceGroupName "your-rg" -Name "your-app-name" | Select-Object -ExpandProperty Identity

Success Metrics

Track these indicators to confirm successful implementation:

Configuration Status: Green checkmarks in Application Settings
Secret Resolution: Keys display @Microsoft.KeyVault(...) format
Authentication Success: Application logs show successful secret retrieval
Performance: No increased latency in secret access operations
Security: Proper RBAC permissions and access policies in place

Conclusion

This comprehensive guide resolves Azure App Service KeyVault Reference Identity configuration issues by addressing the hidden keyVaultReferenceIdentity property problem. The solution enables proper authentication between Azure App Service and Azure Key Vault through Managed Identity integration.

By following this step-by-step approach, developers can successfully:

Configure KeyVault Reference Identity using PowerShell
Verify secret resolution in application settings
Implement proper security and RBAC permissions
Use alternative methods like Azure CLI or infrastructure as code

The hidden property may be invisible in the Azure Portal, but with this technical approach, developers can overcome this architectural limitation and maintain secure, compliant secret management for their Azure applications.

For ongoing maintenance, remember to review identity assignments quarterly, monitor configuration changes, and implement automated secret rotation policies to ensure continued security and compliance.

This article covers advanced Azure administration concepts. Ensure you have proper permissions and understand the implications before making changes to production environments.

Astro + Cloudflare Pages vs WordPress - A Technical Comparison for Modern Static Sites

Harsh Gupta — Fri, 17 Jul 2026 00:00:55 +0000

1. Introduction

In 2026, many teams still default to WordPress when building blogs or marketing sites, often without fully considering the architectural alternatives. The classic WordPress setup PHP on shared hosting or managed WordPress platforms, coupled with a MySQL database and a plugin ecosystem works reliably but comes with inherent performance trade-offs.

Modern visitors now expect lightning-fast page loads and perfect Core Web Vitals a bar that traditional WordPress setups struggle to meet without extensive optimization and caching strategies.

This article examines why, for many developer-managed websites, Astro + Cloudflare Pages delivers superior results in performance, SEO, security, and maintainability compared to traditional WordPress deployments. We'll explore the technical trade-offs and help you make an informed decision for your next blog or business website.

2. What is Astro + Cloudflare Pages?

Astro is a modern web framework that prioritizes delivering fast, lightweight content by default. Instead of running client-side JavaScript on every page load, Astro generates complete HTML during build time. Only interactive elements—dubbed "islands of interactivity"—run JavaScript, and only when needed.

Cloudflare Pages is a globally distributed static hosting platform that leverages Cloudflare's edge network for content delivery. Think of it as Git combined with Cloudflare's CDN and security stack with integrated CI/CD, zero-downtime deployments, and automatic edge caching.

How they work together:

You write your content and components using Astro's Markdown, MDX, or frameworks
Astro builds your site to static HTML during your CI/CD pipeline
Cloudflare Pages takes the built static assets and deploys them to edge locations worldwide
Every request hits the nearest edge location, serving cache-optimized HTML directly

This contrasts sharply with WordPress, which typically involves:

PHP processing on every request
Database queries to fetch content
Server-side template rendering
Dynamic page generation per visitor

The result: WordPress delivers pages via server-side rendering, while Astro + Cloudflare Pages delivers pages via edge-based static serving.

3. Performance and Core Web Vitals: Astro vs WordPress

Why Astro Sites Are Typically Faster

Astro sites start with a clean slate: static HTML by default. This means:

Zero JavaScript by default – Pages load instantly with just HTML
Minimal HTTP requests – Bundles are eliminated from the initial response
Small page weight – Often under 50KB for content pages
Instant first paint – No rendering blockers

Real-world tests and case studies consistently show Astro sites achieving near-perfect Lighthouse performance scores. The initial page load times typically range from 0.5s to 1.5s for content-heavy sites, compared to 2s to 5s for typical WordPress installations.

WordPress Performance Challenges

WordPress usually involves several performance bottlenecks:

PHP rendering on every request – Server-side template processing delays first byte
Database queries – MySQL lookups add tens to hundreds of milliseconds
Plugin overhead – Even maintenance plugins add significant JavaScript and processing
Theme scripts – Most themes include jQuery and other bloat by default

Core Web Vitals Impact

These differences translate directly into Core Web Vitals:

LCP (Largest Contentful Paint) – Astro typically achieves under 1.5s, while WordPress often lands between 2-3s without extensive caching
CLS (Cumulative Layout Shift) – Astro's static nature means predictable layouts. WordPress experiences frequent layout shifts during dynamic content loading
FID (First Input Delay) – Lower JavaScript payloads in Astro mean better interactivity
FCP (First Contentful Paint) – Static HTML delivers content instantly, while WordPress waits for PHP to parse and render

The performance gap becomes more pronounced on mobile networks and in regions far from hosting servers. Since Cloudflare Pages serves content from their global edge network, the geographic distance factor disappears entirely.

4. SEO Benefits of Astro + Cloudflare Pages

Static HTML vs Dynamic Rendering

Static HTML serves SEO exceptionally well because:

Fast pages are prioritized by Google – Poor Core Web Vitals directly impact rankings
Simple, crawlable markup – Search engines can parse clean HTML instantly without JavaScript
Predictable content delivery – Same markup for all visitors regardless of device or traffic source

WordPress's JavaScript-heavy pages force Googlebot to execute JavaScript a process that's become more sophisticated but still less reliable than serving static HTML.

Astro's SEO Capabilities

Astro offers granular control over SEO elements:

---
title: "Your Page Title"
description: "Page description for SEO"
keywords: ["keyword1", "keyword2"]
---
<head>
  <meta property="og:title" content="Social Share Title" />
  <meta property="og:description" content="Social description" />
  <meta property="og:image" content="/social-image.png" />
  <link rel="canonical" href="https://your-site.com/page-url" />
</head>

Content collections and frontmatter provide structured data management:

// src/content/articles/
export interface ArticleSchema {
  title: string;
  publishDate: string;
  excerpt: string;
  author: string;
  tags: string[];
  image?: string;
}

Astro integrates seamlessly with popular SEO tooling:

Robots.txt generation via Astro's sitemap integration
Structured data through @astrojs/sitemap and JSON-LD
Meta tags automatically generated from frontmatter
Image optimization via @astrojs/image, supporting WebP, lazy loading, and responsive sizes

Cloudflare's SEO Advantages

Cloudflare Pages provides several SEO-specific benefits:

Global CDN distribution – Pages serve from 280+ edge locations
Zero-Time to First Byte (TTFB) – Edge caching eliminates server latency
Built-in SSL/HTTPS – No mixed content warnings
Automatic performance optimization – Image compression, HTML minification

These factors combine to create a superior SEO foundation where pages load in under 500ms with perfect Core Web Vitals, immediately signaling relevance to search engines.

Real SEO Impact

The combination of fast performance, clean HTML, and reliable crawling translates to:

Faster indexing – Pages crawled and ranked immediately
Higher visibility – Better Core Web Vitals improve rankings
Better user engagement – Faster pages reduce bounce rates and increase dwell time
Improved Zero-Click Searches – Perfect page structure for featured snippets and search features

5. Developer Experience and Workflow

Astro + Cloudflare Pages Developer Experience

Modern developer workflows prioritize speed and reliability:

# .github/workflows/deploy.yml
name: Deploy to Cloudflare Pages
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm install
      - run: npm run build
      - name: Publish to Cloudflare Pages
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CF_PAGES_API_TOKEN }}
          accountId: ${{ secrets.CF_ACCOUNT_ID }}
          project: my-blog
          directory: ./dist
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

Key benefits include:

Commit → Deploy – Automatic deployments directly from git branches
Zero infrastructure management – No cPanel, FTP, or server administration
Consistent environments – Same code runs identically across dev, staging, and prod
Version control for content – Content is text files, fully version-controlled

WordPress Workflow Comparison

Traditional WordPress workflows involve:

Content management through admin dashboard – HTML editors, plugin dependencies
Theme and plugin management – Version control challenges for non-developers
Performance tuning – Caching plugins, database optimization, CDN integration
Security maintenance – Regular updates, vulnerability patches, backup systems

The WordPress approach demands significant operational overhead to achieve acceptable performance, while Astro + Cloudflare Pages delivers optimal performance by design.

6. A Side-by-Side Comparison

Quick Reference Table

Feature	Astro + Cloudflare Pages	WordPress
Performance	Static HTML by design, edge delivery	Dynamic PHP rendering, database queries
Core Web Vitals	Excellent LCP (under 1.5s), CLS, FID by default	2-3s LCP, frequent CLS without tuning
Learning Curve	Moderate (JavaScript/TypeScript)	Low (PHP/WordPress admin)
Content Management	File-based (Markdown/MDX) or Git-based	Visual editor (Gutenberg)
Out-of-the-Box Features	Limited (static sites)	Extensive (plugins for everything)
Customization	Framework-based (Astro, React, Vue)	Theme/plugin ecosystem
Scalability	Automatic (CDN, edge caching)	Manual (server, caching setup)
Security	Strong (no runtime, Cloudflare WAF)	Moderate (plugins, PHP vulnerabilities)
Maintenance	Low (CI/CD pipelines, static assets)	High (updates, backups, plugins)
SEO	Excellent (fast, clean HTML)	Good (with optimizations)

Price Comparison

Aspect	Astro + Cloudflare Pages	WordPress
Hosting	Free tier available, Pay-as-you-go ($5-20/month)	Shared hosting ($10-50/month) or Managed ($25-100/month)
Development Tools	Free (Astro, Node.js, Git)	Free (WordPress core)
Premium Extensions	Limited (Astro integrations)	Many ($30-200+/year for premium plugins)
Design Themes	Open source, paid ($20-100)	Thousands free, premium ($50-500+)
Support	Community, Cloudflare docs	Extensive docs, commercial support
Total Monthly Cost	$5-30 (estimated)	$60-180 (estimated)

Cost Breakdown:

Astro + Cloudflare Pages: Only pay for Cloudflare usage ($5-20/month for hobby plan, $20-100+ for pro tier)
WordPress: Hosting ($10-50/month) + Premium plugins/themes ($20-100+/year) + Maintenance costs

When to Choose Each Platform

Decision Factor	Choose Astro + Cloudflare Pages	Choose WordPress
Performance Priority	✅ Yes	❌ No
Developer Team	✅ Yes (dev-first approach)	✅ Yes (content-first approach)
Non-Technical Users	❌ No (requires development)	✅ Yes (visual editor)
Complex Features	❌ Limited (static nature)	✅ Extensive (plugin ecosystem)
Budget Constraints	✅ Lower monthly costs	❌ Higher monthly costs
Technical Team	✅ Developer expertise available	✅ Available (WordPress skills)
Growth Plans	✅ Automatic scalability	❌ Manual scaling required

Decision Tree Summary

Performance is critical? → Astro + Cloudflare Pages
Non-technical content creators needed? → WordPress
Complex dynamic features required? → WordPress
Budget is a primary concern? → Astro + Cloudflare Pages
Developer-first approach preferred? → Astro + Cloudflare Pages
Existing WordPress investment? → Consider WordPress (but evaluate migration ROI)

Bottom Line Recommendation

**For most modern developer-managed projects, especially blogs, documentation sites, and marketing pages:

Total Cost: ~60-70% less with Astro + Cloudflare Pages
Performance: Significantly better (0.5s vs 2-5s load times)
Maintainability: Much easier (CI/CD vs ongoing administration)
Security: Stronger (no database, fewer attack vectors)
Developer Experience: Superior (modern toolchain vs legacy admin)

Choose WordPress when you need:

Visual content editing without code
Complex plugin ecosystems (e-commerce, memberships)
Existing WordPress team skills
Rapid feature deployment without developer involvement

This comparison should make it crystal clear which platform serves your specific needs best, with the financial implications being a major deciding factor in 2026's cost-conscious environment.

7. Practical Comparison Scenarios

Scenario 1: SaaS Marketing Site

WordPress approach: Typical SaaS marketing site would require multiple plugins for lead generation, analytics, and contact forms. Performance optimization needs caching plugins, CDN integration, and database cleanup. Security requires Wordfence or similar WAF.

Astro + Cloudflare Pages approach: Lead form implemented via Astro's forms API or a lightweight service like Netlify Forms. Analytics with Astro integrations. Simple, fast pages that convert better due to performance.

Why Astro wins: Marketing sites benefit immediately from faster loads and better SEO. The lightweight approach reduces maintenance overhead and improves conversion rates.

Scenario 2: Developer Technical Blog

WordPress approach: Technical blog with code blocks. Requires syntax highlighting plugins, potentially heavy. Each post loads JavaScript for commenting, related posts, and social sharing. Database queries slow down the blog index page.

Astro + Cloudflare Pages approach: Syntax highlighting built into Astro syntax highlighting. Comments via third-party services (Disqus, Utterances). Static generation means instant page loads even with hundreds of posts.

Why Astro wins: Developer audiences expect fast loading, especially for code-heavy content. Static generation eliminates database overhead and delivers instant page loads.

WordPress remains viable for:

News sites with tight publishing deadlines
Sites requiring complex dynamic features (membership, e-commerce)
Organizations with non-technical content teams
Existing WordPress investments with extensive custom development

8. Migration Considerations

Moving from WordPress to Astro requires careful planning:

URL Preservation:

Use redirects to maintain SEO equity
Implement 301 redirects for changed URLs
Consider using tools like next-redirect or Cloudflare's redirect rules

SEO Transition:

<!-- Preserve schema.org markup -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Article Title",
  "datePublished": "2026-06-24",
  "author": {
    "@type": "Person",
    "name": "Author Name"
  }
}
</script>

Content Migration Strategy:

# Map old URLs to new structure
for page in $(mysql -e "SELECT post_name FROM wp_posts WHERE post_type='post'"); do
  old_url="/$page"
  new_url="/blog/$page"
  echo "$old_url 301  $new_url" >> redirects.txt
 done

Search Console Updates:

Submit updated sitemap.xml
Monitor crawl rate changes
Verify canonical tags are set correctly

9. Conclusion

The choice between WordPress and Astro + Cloudflare Pages depends heavily on your specific use case, team expertise, and long-term goals. However, for most modern blogs, documentation sites, and business websites, Astro + Cloudflare Pages provides the superior foundation.

When to Choose Astro + Cloudflare Pages:

You need performance first – When Core Web Vitals and user experience are priorities
You have developer expertise – When your team can manage content through code and version control
You want low maintenance – When you prefer simplicity over extensive plugin ecosystems
You need global reach – When serving users worldwide with consistent performance
You prioritize SEO – When search rankings and visibility are critical

Key Advantages Recap:

Zero-compromise performance – Static HTML serves instantly from edge locations
Developer-friendly workflows – Git-based deployment and modern CI/CD
Strong security posture – No database, less attack surface, Cloudflare protection
SEO-ready by design – Fast pages, clean markup, global distribution
Scalable architecture – Handles growth without performance degradation

WordPress still holds value in specific scenarios, but for performance-critical, developer-managed sites in 2026, Astro on Cloudflare Pages represents the modern standard for web development.

Ready to prototype your next blog or marketing site using this approach? Start with Astro's starter templates and Cloudflare Pages' Git integration then measure your performance gains and SEO improvements against your current WordPress installation. The difference in user experience and search rankings will speak for itself.

Why Use Repository Pattern in Angular Applications - Best Practices

Harsh Gupta — Sun, 14 Jun 2026 07:21:11 +0000

In modern Angular applications, managing data efficiently is crucial for performance and maintainability. The Repository Pattern provides a clean abstraction layer between your components and data sources, offering significant benefits for enterprise applications.

What is the Repository Pattern?

The Repository Pattern is an architectural approach that acts as a mediator between the data source (database, API, etc.) and the business logic layers of an application. Rather than making direct API calls from components, you use repository services that:

Centralize data access logic in one place
Provide caching mechanisms to reduce redundant network requests
Offer reactive observables for data changes
Handle data loading and initialization

Why Vineforce Teams Uses This Pattern

At Vineforce, we've adopted the Repository Pattern for several key reasons:

Performance Optimization

Reduces redundant API calls through intelligent caching
Minimizes network overhead by storing frequently accessed data
Enables optimistic UI updates for better user experience

Code Maintainability

Centralizes data access logic in one place
Promotes separation of concerns
Makes components cleaner and more testable
Simplifies debugging and troubleshooting

Developer Productivity

Provides consistent API across different data types
Enables reactive programming patterns
Reduces boilerplate code in components

Implementation in Vineforce Teams

Base Repository Class

Our implementation starts with an abstract Repository class:

export abstract class Repository<T extends { id: number }> {
    protected dic: { [id: number]: T };
    protected items: T[];

    /** Provides an observable that will emit a new list every time a change occurs */
    public observe(): Observable<T[]>;

    /** Returns the item having that ID, only if already loaded in the repository */
    public get(id: number): T;

    /** Returns the item if present in the repository, otherwise loads it */
    public getOrLoad(id: number): Promise<T>;

    /** Adds a range of items to the repository */
    public addRange(ts: T[]): void;

    /** Removes a range of items from the repository */
    public removeRange(ts: T[]): void;

    protected abstract loadAll(): Promise<T[]>;
}

Concrete Implementation Example

Here's how we extend the base class for team member data:

@Injectable({
    providedIn: 'root'
})
export class TeamMemberNamesRepositoryService extends Repository<TeamMemberNameDto> {

    constructor(
        private userService: UserServiceProxy
    ) {
        super();
        this.initialLoad(); // Pre-load data when service is instantiated
    }

    protected loadAll(): Promise<TeamMemberNameDto[]> {
        return this.userService.getTeamMembersByCurrentUser()
            .pipe(map(members => members.map(n => ({ id: n.value, name: n.name }))))
            .toPromise();
    }
}

export interface TeamMemberNameDto {
    id: number;
    name: string;
}

Benefits for Vineforce Teams Developers

1. Reduced API Calls

With caching built into repositories, common data is only fetched once and reused across components:

// Multiple components can access the same data without additional API calls
const teamMembers$ = this.teamMemberRepository.observe();

2. Consistent Data State

All components using the same repository share the same data state, ensuring consistency:

// When data updates in one place, all components automatically reflect changes
this.teamMemberRepository.entityChanged(updateEntity(updatedMember));

3. Simplified Component Logic

Components focus on presentation logic rather than data management:

@Component({
  selector: 'app-team-selector',
  template: `
    <select [(ngModel)]="selectedTeamMember">
      <option *ngFor="let member of teamMembers$ | async" [value]="member.id">
        {{ member.name }}
      </option>
    </select>
  `
})
export class TeamSelectorComponent implements OnInit {
  teamMembers$ = this.teamMemberRepository.observe();

  constructor(
    private teamMemberRepository: TeamMemberNamesRepositoryService
  ) {}

  ngOnInit() {
    // Repository handles loading automatically
  }
}

Best Practices for Repository Implementation

1. Initialize Early

Load frequently used data early in the application lifecycle:

constructor(private userService: UserServiceProxy) {
    super();
    this.initialLoad(); // Load data when service is created
}

2. Handle Loading States

Repositories provide built-in mechanisms for handling loading states:

// Check if repository is ready
if (this.repository.isReady) {
  // Repository has loaded data
  this.repository.isReady.then(items => {
    // Process loaded items
  });
}

3. Update Repository on Data Changes

Keep repositories synchronized with backend changes:

// When an item is created/updated/deleted
this.repository.entityChanged(insertEntity(newItem));
this.repository.entityChanged(updateEntity(updatedItem));
this.repository.entityChanged(deletedEntity(removedItem));

When to Use Repository Pattern

The Repository Pattern is particularly beneficial when:

You have data that is used across multiple components
You need to minimize network requests
You want to implement caching strategies
You need to maintain consistent data state across your application
You're building enterprise applications with complex data relationships

Conclusion

The Repository Pattern provides a robust and scalable approach to data management in Angular applications. By centralizing data access and implementing intelligent caching, repositories significantly improve both application performance and developer productivity.

Key advantages of this pattern include:

Reduced API calls through caching
Cleaner component code
Consistent data access patterns
Built-in reactive programming support
Easy synchronization with backend changes

This pattern is especially valuable in enterprise applications like Vineforce Teams where multiple components need access to the same data sets, ensuring optimal performance and maintainability.

For developers working with Vineforce Teams, understanding and utilizing the Repository Pattern will lead to more efficient, maintainable, and performant applications.

DefaultAzureCredential vs Client ID & Client Secret for Azure Key Vault Authentication

Harsh Gupta — Sun, 14 Jun 2026 07:20:28 +0000

Securely accessing Azure Key Vault is essential for modern cloud applications. This guide compares the DefaultAzureCredential (recommended) and the classic Client ID & Client Secret authentication methods for Azure Key Vault, providing best‑practice recommendations, security considerations, and ready‑to‑use C# code samples.

The Two Approaches

1. DefaultAzureCredential

DefaultAzureCredential is a composite credential that sequentially attempts a set of credential sources (environment variables, managed identity, Visual Studio, Azure CLI, etc.) until one succeeds. It is designed to work out‑of‑the‑box in local development, CI pipelines, and production environments. Azure SDK authentication overview (Azure Identity)

2. Client ID & Client Secret

The Client ID & Client Secret method uses an Azure AD App Registration. You explicitly provide the tenantId, clientId, and clientSecret to the ClientSecretCredential. This is a static credential that does not change based on the runtime environment.

Comparison Table

Aspect	DefaultAzureCredential	Client ID & Client Secret
Security	Leverages managed identities in Azure, never stores secrets in code or config. Secrets only exist in dev environment as env vars.	Secret stored in configuration (env var, file, or secret store). Higher risk of leakage.
Local Development	Works with Azure CLI, VS Code, or environment variables automatically. No extra code changes when moving between dev and prod.	Requires developers to provision and manage a secret locally, often duplicated across machines.
Production Overhead	Zero‑code changes when deploying to Azure services (App Service, AKS, Functions) that support Managed Identity.	Must provision secret in each target environment (e.g., Azure Key Vault, App Settings).
Credential Rotation	Managed identity tokens rotate automatically; no manual secret rotation needed.	Secret rotation is manual – you must update the secret in every deployment artifact.
Compliance	Aligns with Azure recommended best practices (least‑privilege, short‑lived tokens).	May conflict with policies that forbid storing secrets in configuration files.
Complexity	Slightly larger package size but simplifies code paths.	Simpler code but adds operational complexity around secret handling.
Supported Languages	All Azure SDKs that use Azure.Identity.	All Azure SDKs that accept a TokenCredential.

Pros & Cons

DefaultAzureCredential

Pros

Automatic credential selection across environments.
Seamless integration with Managed Identity – no secrets in production.
Simplifies CI/CD pipelines.
Recommended by Microsoft for new projects.

Cons

Slightly larger dependency footprint.
Requires understanding of the credential chain for debugging.

Client ID & Client Secret

Pros

Explicit and deterministic – you know exactly which credential is used.
Works in environments that lack Azure SDK support for managed identity.

Cons

Secrets must be stored and rotated manually.
Higher risk of accidental exposure (e.g., committing to repo).
Additional operational overhead for each deployment target.

When to Use Which

Scenario	Recommended Approach
New cloud‑native application running in Azure (App Service, AKS, Functions, etc.)	DefaultAzureCredential – take advantage of managed identity.
Legacy on‑prem or non‑Azure environment where managed identity isn’t available	Client ID & Client Secret – you must supply a static credential.
Quick prototype on a developer machine without Azure CLI installed	Either works, but DefaultAzureCredential still recommended for consistency.
Strict compliance requiring no secrets in configuration files	DefaultAzureCredential (managed identity) is the only compliant choice.

Code Samples (C# using Azure.Identity)

1. Using DefaultAzureCredential

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

// The credential automatically picks the best source:
// - Azure Managed Identity (production)
// - Azure CLI / Visual Studio credentials (local dev)
var credential = new DefaultAzureCredential();

var vaultUrl = new Uri("https://my-keyvault.vault.azure.net/");
var client = new SecretClient(vaultUrl, credential);

// Retrieve a secret
KeyVaultSecret secret = await client.GetSecretAsync("MySecret");
Console.WriteLine($"Secret value: {secret.Value}");

2. Using Client ID & Client Secret

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string tenantId   = Environment.GetEnvironmentVariable("AZURE_TENANT_ID");
string clientId   = Environment.GetEnvironmentVariable("AZURE_CLIENT_ID");
string clientSecret = Environment.GetEnvironmentVariable("AZURE_CLIENT_SECRET");

var credential = new ClientSecretCredential(tenantId, clientId, clientSecret);

var vaultUrl = new Uri("https://my-keyvault.vault.azure.net/");
var client = new SecretClient(vaultUrl, credential);

KeyVaultSecret secret = await client.GetSecretAsync("MySecret");
Console.WriteLine($"Secret value: {secret.Value}");

Note: In production, store the environment variables securely (e.g., Azure App Service Application Settings or Azure Key Vault references). Never hard‑code secrets.

Conclusion

References

Azure SDK authentication overview (Azure Identity)
DefaultAzureCredential class documentation
ClientSecretCredential class documentation
Azure Key Vault authentication guide
Managed identities for Azure resources

DefaultAzureCredential is the recommended standard for modern Azure applications. It provides a unified, secure, and low‑maintenance authentication experience that works consistently from local development to production with managed identities. The explicit Client ID & Client Secret approach still has a place for legacy or non‑Azure scenarios, but it introduces secret management overhead and security risk. Adopt DefaultAzureCredential wherever possible to align with Azure’s best‑practice security model.

Docusaurus – The Modern Docs Framework

Harsh Gupta — Sun, 14 Jun 2026 07:20:26 +0000

1. What is Docusaurus?

Docusaurus is an open‑source static‑site generator focused on documentation. Built and maintained by Meta (formerly Facebook), it lets you create, version, and deploy documentation sites with zero configuration or full customisation using React, Markdown, and MDX.

Feature	What it means
Static‑site generation	Pre‑renders pages to plain HTML → fast loads, cheap hosting.
React‑powered	Use React components inside your docs (MDX).
Zero‑config defaults	npm init docusaurus gives you a working site in seconds.
Extensible plugin ecosystem	Add search, analytics, theme tweaks, etc., without touching core code.

2. Why Developers & Organizations Should Use It

Speed to ship – A working docs site is ready after npm start.
Maintainable codebase – Docs live alongside source code, enabling PR‑driven updates.
Scalable – Handles single‑page docs to multi‑version portals with the same build pipeline.
Community & Vendor backing – Backed by Meta, with an active ecosystem of plugins and themes.

TL;DR: If you already use React or a Node‑based build system, Docusaurus fits naturally and reduces the overhead of maintaining separate documentation tooling.

3. Key Features & Benefits

Feature	Benefit	Example
Built‑in versioning	Publish docs for each app release; users can switch versions.	npx docusaurus docs:version 2.3.0
Markdown + MDX	Write prose in Markdown, embed React components when needed.	See MDX example below.
Search (Algolia, Lunr, etc.)	Instant full‑text search without external services (optional).	npm install @docusaurus/theme-search-algolia
Blog support	Publish release notes, tutorials, or team updates side‑by‑side with docs.	npx docusaurus blog:write
Theming & Customisation	Override theme files or create a custom React theme.	npm run swizzle @docusaurus/theme-classic
Plugin ecosystem	Add sitemap, RSS, Google Analytics, PWA, and more with a single line in docusaurus.config.js.	plugins: ['@docusaurus/plugin-sitemap']
CI/CD‑ready	Generates static assets (/build) – easy to cache on CDNs.	npm run build && npx serve ./build
Multi‑platform deployment	Works on GitHub Pages, Azure Static Web Apps, Cloudflare Pages, Netlify, Vercel, etc.	gh-pages -d build
Internationalisation (i18n)	Create docs in multiple languages with locale‑aware routing.	i18n: { defaultLocale: 'en', locales: ['en','fr','zh'] }

4. Simplifying Documentation Management

Docs live in the repo – No separate repository or wiki.
PR‑driven updates – Docs are changed through normal code review flow.
Automatic linking – [@site] URLs resolve to the site’s base URL, avoiding hard‑coded links.
Consistent styling – A single theme ensures all pages look identical, reducing UI drift.

Typical Workflow

# 1️⃣ Create a new page
npx docusaurus docs:create my-new-feature

# 2️⃣ Write Markdown/MDX (edit docs/my-new-feature.md)

# 3️⃣ Run locally
npm start

# 4️⃣ Open PR → review → merge

# 5️⃣ CI builds & deploys automatically

5. CI/CD & Deployment

Because Docusaurus outputs static HTML, any CI system can treat it like a normal build artifact.

# Example GitHub Actions workflow (docusaurus.yml)
name: Deploy Docusaurus site
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build
      - name: Deploy to Cloudflare Pages
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CF_PAGES_TOKEN }}
          projectName: docusaurus-docs
          directory: ./build

      # Cloudflare Pages offers a generous free tier (up to 500 build minutes per month and unlimited bandwidth), perfect for open‑source docs. No credit‑card is required, and you can preview changes on PRs automatically.

Replace the cloudflare/pages-action step with gh-pages, Azure/static-web-apps-deploy, or Netlify steps as needed.

6. Versioning Support

# Create a new version folder (e.g., v2.0)
npx docusaurus docs:version 2.0

Docusaurus copies the current docs/ folder into versioned_docs/version‑2.0/.
A selector component appears automatically, letting visitors pick the version they need.

Best‑Practice Tips

Version only on major releases – Keeps the version list short.
Maintain a changelog – Use the built‑in blog or a dedicated CHANGELOG.md.

7. Markdown & MDX

Markdown – Perfect for plain text, tables, code fences.
MDX – Allows JSX inside docs, letting you embed live components, charts, or interactive demos.

# My Component Demo

Here is a live React chart:

import { BarChart } from '@site/src/components/BarChart';
<BarChart data={chartData} />

When to use MDX? When you need dynamic UI (e.g., visualising API responses) or want to reuse existing React components.

8. Search Functionality

Algolia DocSearch (recommended for large sites) – Free tier for open‑source projects.
Lunr.js – Zero‑config, client‑side index for smaller docs.

// docusaurus.config.js – Algolia example
themeConfig: {
  algolia: {
    appId: 'YOUR_APP_ID',
    apiKey: 'YOUR_SEARCH_ONLY_API_KEY',
    indexName: 'your-site',
    contextualSearch: true,
  },
},

9. Blog & Documentation Features

Area	What Docusaurus Provides
Blog	Markdown‑based posts, RSS feed, pagination.
Docs	Sidebar auto‑generation, version dropdown, edit‑URL links back to source.
Pages	Free‑form React pages (src/pages).
Internationalisation	Language switcher + per‑locale routes.

10. Customisation & Plugin Ecosystem

Theme Swizzling – Override any component by copying it into src/theme.
Official Plugins – @docusaurus/plugin-content-docs, @docusaurus/plugin-content-blog, @docusaurus/plugin-google-analytics, etc.
Community Plugins – docusaurus-plugin-sitemap, docusaurus-plugin-pwa, docusaurus-plugin-openapi.

Quick Custom Theme Example

npx docusaurus swizzle @docusaurus/theme-classic Navbar

Edit src/theme/Navbar/index.js to add a custom logo or extra navigation items.

11. Integration with CI Platforms

Platform	Typical Integration
GitHub	Use GitHub Actions to run npm run build → gh-pages deploy.
Azure DevOps	Add a pipeline step calling npm run build and publish the build/ folder to an Azure Static Web App.
Cloudflare Pages	Push the build/ directory to a Cloudflare Pages project; automatic preview URLs on PRs.

All integrations rely on the same static artifact (/build).

12. Real‑World Use Cases

Company	Use‑case
Meta	Internal product documentation for React Native and Jest.
Microsoft	Docs for VS Code extensions, hosted on GitHub Pages.
Airbnb	Public API reference & design system docs with versioning.
Open‑Source Projects (e.g., TensorFlow.js, Storybook)	Community‑maintained docs, searchable, with a blog for release notes.

13. Comparisons with Traditional Approaches

Traditional Docs (e.g., MkDocs, Jekyll)	Docusaurus
Static‑only (no React)	React + MDX – interactive demos possible
Limited versioning	Built‑in versioning via CLI
Plugin ecosystem	Rich, officially supported plugins + community
Zero‑config start	npm init docusaurus gives a complete site instantly
TypeScript support	Full TS in custom components and config

14. Best Practices & Recommendations

Keep docs in the same repo as the code they describe.
Use versioning for every public release.
Leverage MDX for component demos; avoid over‑using React in simple prose.
Enable Algolia DocSearch for larger sites (free for OSS).
Add a “Edit this page” link – editUrl in docusaurus.config.js encourages community contributions.
Automate deployment in your CI pipeline – a single npm run build && deploy-step is enough.
Monitor bundle size – Docusaurus ships a default theme (~200 KB gzipped); prune unused plugins for faster builds.

15. References

Official site & docs – https://docusaurus.io
GitHub repo – https://github.com/facebook/docusaurus
Algolia DocSearch – https://docsearch.algolia.com/
“Getting Started” tutorial – https://docusaurus.io/docs/next/installation
Blog post on versioning – https://docusaurus.io/docs/next/versioning

Ready to publish? Save this file as docusaurus-overview.md (or any slug you prefer) and run the CLI if you want to regenerate, or edit directly. Let me know if you need any further tweaks.

How to Add a Module in the ABP.io Application?

Harsh Gupta — Wed, 23 Jul 2025 09:45:19 +0000

If you’re building your application with ABP.io, you’re already on the right path to creating scalable and professional software. One of the best things about ABP.io is how it supports modular architecture. But what does that really mean?

In simple words, a module in ABP.io is like a complete feature package. It comes with its own logic, database setup, APIs, and even user interface parts. Think of it as a plug-and-play part of your application that keeps your code clean, reusable, and easy to manage.

ABP.io provides many useful built-in modules like Identity, Tenant Management, and Audit Logging. These help you quickly add common features without writing everything from scratch.

But sometimes, you need to go beyond the default options. Maybe your project has unique requirements. That’s when creating a custom module becomes important.

In this guide, I’ll show you how to add a custom module, like Vineforce.ProjectManagement, into your existing ABP.io application. You’ll learn how to do it step by step on both the backend using .NET and the frontend using Angular.

Whether you’re just starting with ABP.io or already have experience, this blog is made to help you integrate modules smoothly and with confidence.

What You’ll Learn in This Guide

How to prepare your system for module integration
How to add the module to your ABP.io backend using NuGet
How to configure the database context and migrations
How to link the Angular frontend with the module using npm
Common pitfalls to avoid during integration

Step 1: Prerequisites & Setup
Before you begin, make sure the following tools and environments are set up properly.

1.1 Required Software

.NET SDK (compatible with your ABP.io version)
Node.js and npm
Angular CLI (installed globally)
ABP CLI (installed via dotnet tool)
Visual Studio or Rider for .NET
Git for version control

1.2 ABP.io Application Ready

Ensure you have an existing ABP.io application up and running. The application should be in either Modular Monolith or Microservice architecture.

Step 2: Backend Integration Using NuGet (C# / .NET)

We’ll start by connecting your backend application to the custom module using NuGet packages.

2.1 Add Required Packages "Vineforce.Admin.HttpApi.Host"

Vineforce.ProjectManagement.Application
Vineforce.ProjectManagement.HttpApi

2.2 Register Module Dependencies

Open the file AdminHttpApiHostModule.cs
Add the module dependencies inside the [DependsOn] attribute:

[DependsOn(
    typeof(ProjectManagementHttpApiModule),
    typeof(ProjectManagementApplicationModule),
    typeof(ProjectManagementEntityFrameworkCoreModule),
    typeof(ProjectManagementDomainSharedModule)
)]

Also, add the using statements at the top:

using Vineforce.ProjectManagement;
using Vineforce.ProjectManagement.EntityFrameworkCore;

2.3 Add Required Packages "Vineforce.Admin.EntityFrameworkCore"

Also, add the using statements at the top:

Vineforce.ProjectManagement.EntityFrameworkCore

2.4 Update Your DbContext

   1. Open AdminDbContext.cs

Inside the OnModelCreating method, add the following:

builder.ConfigureProjectManagement();

This step tells your database context to load and apply table configurations from the ProjectManagement module.

2.5 Apply Migrations

Once you update the DbContext, run EF Core migrations to apply the updated schema to your database.

Option A: Using Terminal / PowerShell

cd src/Vineforce.Admin.EntityFrameworkCore
dotnet ef migrations add Add_ProjectManagement_Module
dotnet ef database update

At this point, the new tables from the module will be added to your main database.

Step 3: Frontend Integration Using npm (Angular)

Once the backend is configured, let’s integrate the Angular frontend with the module.

3.1 Install the Angular Module

Open your Angular project root (usually /angular)
Run this command in the terminal:

npm i @vineforce-modules/project-management

You can view this link to copy the command: @vineforce-modules/project-management
This will also add the following entry in package.json:

"@vineforce-modules/project-management": "^9.0.0"

3.2 Update the app-routing.module.ts file

{
  path: 'project-management',
  loadChildren: () =>
    import('@vineforce-modules/project-management').then(m => m.ProjectManagementModule.forLazy()),
},

This step makes the ProjectManagement module visible in the frontend UI.

Step 4: Test the Integration

Now that everything is configured, it’s time to test.

4.1 Backend Checklist

Run the application using Visual Studio or dotnet run
Check if there are any build errors
Confirm that new database tables were created

4.2 Frontend Checklist

Run npm start or ng serve for Angular
Log in to the app
Navigate through the new module in the side menu
Test create/edit/delete operations

Common Issues & Troubleshooting

Final Summary

You have now successfully done it.

Added a module to your ABP.io backend
Linked it with your database and ran migrations
Integrated the Angular module using npm
Updated routing and tested the entire module

This setup allows you to build and scale your application using modular principles without repeating core logic again and again.

Conclusion
Adding a custom module to your ABP.io application is not just a technical task, it is a smart way to keep your project scalable and organized. By following this step-by-step guide, you have successfully connected your backend using NuGet, updated your database context, applied migrations, and linked the frontend through npm and Angular routing.

This process helps you avoid repeating code, improves maintainability, and prepares your application for future growth. Whether you are adding one module or planning to build a fully modular system, this method will save time and reduce errors.

If you face any issues or want expert assistance, the Vineforce team is always ready to help with ABP.io development, custom modules, and performance optimization. You can reach us at info@vineforce.net for support or consultation.

Guide to Add Custom Modules in ABP.IO App

Harsh Gupta — Thu, 29 May 2025 06:26:05 +0000

If you want to extend your ABP.IO application with a custom module, like Vineforce.Test—this guide is for you. Whether you’re building a new feature or organizing your code into reusable parts, creating a custom module helps keep your application clean, scalable, and maintainable.

In this guide, we’ll walk through the full integration process step by step, covering both the backend and the Angular frontend. You’ll learn how to properly register the module, configure dependencies, and connect the UI layer to your logic. By the end, you’ll have a working module that’s fully integrated into your ABP.IO solution, following best practices.

No guesswork, no skipping steps—just a clear path to getting your custom module up and running.

Prerequisites

1. Install ABP CLI

If not already installed, run the following command:

dotnet tool install -g Volo.Abp.Cli

2. Create the main Apb.io application with the name “Vineforce.Admin”

abp new Vineforce.Admin -t app -u angular -m none --separate-auth-server --database-provider ef -csf

It creates the structure of backend of main abp application as follows:

3. Configure appsettings.json of the main ABP.IO

Edit the appsettings.json files in the two projects below to include the correct connection strings:

Projects:

Vineforce.Admin.HttpApi.Host
Vineforce.Admin.DbMigrator

4. Create the Module folder in main application as Follow the official guide to create your module:

Official Guide

If you choose Angular as the UI framework (by using the -u angular option), the generated solution will include a folder named angular. This folder contains all the client-side code for the application.

Example: A module named Vineforce.Test was created using the Angular UI option.

1. When you open the angular folder in an IDE, the folder structure will appear as follows:

2. And backend structure as follows:

3. Configure appsettings.json

Edit the appsettings.json file in the Host projects to include correct connection strings:

Projects:

Vineforce.Test.AuthServer
Vineforce.Test.HttpApi.Host
Vineforce.Test.Web.Unified

"ConnectionStrings": { "Default": "Server=servername;Database=Test_Main;Trusted_Connection=True;TrustServerCertificate=True", "Test": "Server=VINEFORCE-SHIVA;Database=Test_Module;Trusted_Connection=True;TrustServerCertificate=True" }

Make sure the server names and database details match your development environment.

4. Apply Database Update

In the Package Manager Console (under the EntityFrameworkCore project), run:

Update-Database

5. Run the Application

Set Vineforce.Test.Web.Unified as the startup project and launch the application using the default credentials:

Username: admin
Password: 1q2w3E*

6. Ensure Redis Is Running

Redis is used for distributed caching. Make sure Redis is installed and running before starting the application.

7. Application Startup Order

Run the following projects in order:

*.AuthServer or *.IdentityServer
*.HttpApi.Host
*.Web.Unified

1. Adding a Module to the Backend of the Main Application

cd C:\Users\Vineforce\source\repos\AbpAdmin

2. Add All Required Projects of the module to the Main ABP.IO Solution

To include various parts of your module (such as Domain, Application, EntityFrameworkCore, and HttpApi) in the main ABP solution, run the following commands:

dotnet sln add modules\vineforce.test\src\Vineforce.Test.Domain\Vineforce.Test.Domain.csproj
dotnet sln add modules\vineforce.test\src\Vineforce.Test.Application\Vineforce.Test.Application.csproj
dotnet sln add modules\vineforce.test\src\Vineforce.Test.EntityFrameworkCore\Vineforce.Test.EntityFrameworkCore.csproj
dotnet sln add modules\vineforce.test\src\Vineforce.Test.HttpApi\Vineforce.Test.HttpApi.csproj

Projects are added as below:

Add Project References Using Visual Studio

In the Vineforce.Admin.HttpApi.Host project: Right-click the project and select “Add” → “Project Reference”.

1. In the dialog that appears, check the following projects:

Vineforce.Test.Application
Vineforce.Test.EntityFrameworkCore
Vineforce.Test.HttpApi

2. Click OK to confirm and add the references.

3. After adding the project > reference, here you can add all module references you want.

In AdminHttpApiHostModule.cs, update the [DependsOn(...)] attribute:.

typeof(TestHttpApiModule),
typeof(TestApplicationModule),
typeof(TestEntityFrameworkCoreModule),
typeof(TestDomainSharedModule)

Also, add the necessary using statements:

using Vineforce.Test;
using Vineforce.Test.EntityFrameworkCore;

Configure the Module in the EntityFrameworkCore Project

To ensure that schema, table mappings, and other Entity Framework configurations from the module are applied in the main ABP.IO application, follow these steps:

Add a Project Reference:

Right-click on the Vineforce.Admin.EntityFrameworkCore project.
Select Add → Project Reference.
Check and add: Vineforce.Test.EntityFrameworkCore

Update the DbContext Configuration

Open AdminDbContext.cs.
Inside the OnModelCreating method, add the following line to apply the module’s configuration:

builder.ConfigureTest();

You can verify this by navigating to the Vineforce.Test.EntityFrameworkCore module and opening the TestDbContext class.

Apply Migrations to Update the Database Schema

After completing the integration steps, you need to apply Entity Framework migrations to reflect the module’s schema changes in the database.

Option 1: Using PowerShell or Terminal

Open a PowerShell or terminal window.
Navigate to the EntityFrameworkCore project directory of your main application, for example:cd src/Vineforce.Admin.EntityFrameworkCore
Run the following command to create a new migration:

dotnet ef migrations add Add_Test_Module

Option 2: Using the Package Manager Console in Visual Studio

Open the Package Manager Console (Tools → NuGet Package Manager → Package Manager Console).
Set the Default Project to src\Vineforce.Admin.EntityFrameworkCore.
Run the following command:

PM> Add-Migration Add_Test_Module

This will generate a new migration that includes all Entity Framework changes from the integrated module.

Then run the following command to apply the migration and update the database:

Update-Database

Steps to add the module application to the main ABP.IO application

Step 1: Build the Angular Module

Navigate to the module’s frontend directory and build the module using the Angular CLI:

ng build test --configuration production

This command compiles the test Angular module in production mode and outputs the build artifacts to the dist folder.

Output folder:
C:\Users\Vineforce\source\repos\AbpAdmin\modules\Vineforce.Test\angular\dist

Step 2: Copy Module Output to Main App

Go to your main app’s angular folder: C:\Users\Vineforce\source\repos\AbpAdmin\angular
Create a projects folder inside it.
Copy the test folder from the dist directory into projects.
Final pathC:\Users\Vineforce\source\repos\AbpAdmin\angular\projects\test

Step 3: Update App Routing

Open app-routing.module.ts in the main app:

C:\Users\Vineforce\source\repos\AbpAdmin\angular\src\app\app-routing.module.ts

In app-routing.module.ts, import the module’s routing configuration and add it to the main route definitions:

{
  path: 'test',
  loadChildren: () =>
    import('test').then(m => m.TestModule.forLazy())
}

Step 4: Link the Module in package.json

Open the package.json file having path C:\Users\Vineforce\source\repos\AbpAdmin\angular add the following line under the “dependencies” section to link your local module:

"test": "file:projects/test"

Then install dependencies:

npm install

You can now see the Test Module API controller in the Swagger UI of the main application.

You can now log in to the main application

The Test module now appears in the main application. You can add, edit, or delete items according to the assigned permissions.

Country ‘Russia’ has been added. You can view, edit, or delete it on the page

You can grant or revoke permission by this following page

Now Edit permission has been disabled for the current user/page.

Currently, the delete option is visible, but the edit option is not showing on the pagepermission has been disabled for the current user/page.

By following this step-by-step guide, you’ve learned how to successfully integrate a custom module—like Vineforce.Test—into your ABP.IO application. From backend setup to Angular frontend integration, you now have a solid foundation for building scalable, maintainable, and modular applications. With best practices in place, your ABP.IO projects are ready to grow more efficiently.

If you're looking for expert help with ABP.IO SaaS development, feel free to reach out to Vineforce. For more tutorials and insights like this, be sure to explore the Vineforce Blog.

DEV Community: Harsh Gupta

How to Configure keyVaultReferenceIdentity in Azure App Service?

Overview

Symptoms

Why This Happens

Technical Architecture

Why Portal Visibility is Limited

Prerequisites

Required Azure Resources

Required Tools and Permissions

Environment Setup

Step-by-Step Solution Guide

Step 1: Prepare Your PowerShell Environment

Step 2: Target the Correct Azure Subscription

Step 3: Execute the ARM Fix Script

Step 4: Complete Verification Process

Restart App Service

Validate Application Settings

Test Secret Access

Success Checklist

Common Issues and Troubleshooting

Issue: "Not Resolved" Errors Persist

Issue: Permission Denied

Issue: Cross-Subscription Access

Security Considerations

Required RBAC Permissions

Security Best Practices

Alternative Implementation Methods

Azure CLI Solution

Infrastructure as Code (Bicep)

Infrastructure as Code (Terraform)

Technical Limitations and Considerations

Current Limitations

Performance Impact

Common Implementation Mistakes

Mistake 1: Premature Script Execution

Mistake 2: Incorrect Subscription Context

Mistake 3: Incomplete Identity URLs

SEO Optimization Keywords

Related Documentation

Quick Reference Commands

PowerShell Commands

Verification Commands

Success Metrics

Conclusion

Astro + Cloudflare Pages vs WordPress - A Technical Comparison for Modern Static Sites

1. Introduction

2. What is Astro + Cloudflare Pages?

3. Performance and Core Web Vitals: Astro vs WordPress

Why Astro Sites Are Typically Faster

WordPress Performance Challenges

Core Web Vitals Impact

4. SEO Benefits of Astro + Cloudflare Pages

Static HTML vs Dynamic Rendering

Astro's SEO Capabilities

Cloudflare's SEO Advantages

Real SEO Impact

5. Developer Experience and Workflow

Astro + Cloudflare Pages Developer Experience

WordPress Workflow Comparison

6. A Side-by-Side Comparison

Quick Reference Table

Price Comparison

When to Choose Each Platform

Decision Tree Summary

Bottom Line Recommendation

7. Practical Comparison Scenarios

Scenario 1: SaaS Marketing Site

Scenario 2: Developer Technical Blog

WordPress remains viable for:

8. Migration Considerations

9. Conclusion

When to Choose Astro + Cloudflare Pages:

Key Advantages Recap:

Further Reading

Why Use Repository Pattern in Angular Applications - Best Practices

What is the Repository Pattern?

Why Vineforce Teams Uses This Pattern

Performance Optimization

Code Maintainability

1. What is Docusaurus?

2. Why Developers & Organizations Should Use It