Shipping multi-platform, secure containers without maintaining complex Dockerfiles is the holy grail for platform engineering. With .NET 11 (Release Candidate 1), Microsoft heavily markets its built-in SDK container publishing as the solution. But marketing claims and CI/CD realities often clash.

After running the .NET 11 RC1 SDK through an isolated sandbox environment—testing everything from cross-compilation to rootless runtimes—here is the unvarnished DevOps breakdown of what actually works, what is overhyped, and how you should adapt your pipelines.

1. SDK-Driven Publishing and the Base Image Reality

The SDK natively understands your .csproj and generates an OCI-compliant image without a single Dockerfile command. Running a simple publish command works effortlessly:

dotnet publish /t:PublishContainer -p:ContainerRepository=my-registry.local/myapp -p:ContainerImageTag=1.0.0

The process takes roughly 6 to 11 seconds. However, contrary to the belief that the SDK defaults to "microscopic" secure images, the default base image pulled is the standard Debian-based aspnet:11.0.0-rc.1, resulting in a ~256MB footprint.

To achieve a minimal attack surface, you must explicitly opt into Ubuntu Chiseled images. In .NET 11, the correct chiseled tag family corresponds to Ubuntu 26.04 (Resolute) rather than Ubuntu 24.04 (Noble). If you rely on auto-inference during the preview/RC phase, the SDK might incorrectly target noble-chiseled and fail, so you must explicitly declare it:

<!-- Add this to your .csproj -->
<ContainerFamily>resolute-chiseled</ContainerFamily>

While marketing sometimes hints at sub-50MB footprints, sandbox testing shows a standard minimal API built on resolute-chiseled clocks in at 128MB uncompressed—still an excellent 50% reduction with zero package managers or shells included.

2. Multi-Architecture: The Massive Win and the Critical Gotcha

Transitioning to ARM64 (like AWS Graviton) saves money, but configuring QEMU and Docker Buildx in CI pipelines is notoriously slow. .NET 11 handles this beautifully at the compiler level.

By passing -r linux-arm64, the SDK cross-compiles the Intermediate Language (IL) natively and constructs the ARM64 container layers on an x64 runner without ever invoking QEMU. This is a massive CI performance win.

The Pipeline Gotcha: You cannot rely on the SDK to build a true multi-architecture tag (a single latest tag that resolves correctly on both architectures). If you run consecutive publish commands for linux-x64 and linux-arm64 pointing to the same registry tag, the second push completely overwrites the first manifest.

To create a genuine multi-arch manifest list, your CI/CD pipeline still requires a manual step.

Key insight: Build and push architecture-specific tags (latest-amd64, latest-arm64) with the SDK, then use docker manifest create or buildah manifest at the end of your pipeline to bind them together.

3. Daemonless CI/CD: Seamless Podman Integration

If your enterprise strictly enforces rootless, daemonless CI/CD agents, .NET 11 is a game changer. Historically, using Podman required brittle DOCKER_HOST socket mapping hacks.

In testing, completely removing Docker from the PATH and installing only Podman resulted in flawless execution. The SDK automatically detects Podman and pushes directly to its local image store. You can finally adopt rootless Podman on RHEL/Ubuntu GitHub Action runners without modifying your dotnet publish commands.

4. Supply-Chain Security: The Reproducibility Illusion

Software Supply Chain standards like SLSA emphasize reproducible builds—the guarantee that the same source code produces the exact same artifact digest.

While the .NET 11 compiler is perfectly deterministic (producing byte-for-byte identical DLLs on identical source code), the resulting container image digest (SHA256) will still change on every build. This occurs because the container packing step embeds the current wall-clock time (mtime) into the headers of the tar filesystem layers. Until the SDK provides a robust SOURCE_DATE_EPOCH injection mechanism, strict bit-for-bit image digest reproducibility requires external tooling.

The DevOps Adoption Checklist

Before ripping out your Dockerfiles for .NET 11, evaluate your pipelines against these verified realities:

1. Validate OS Dependencies: No apt-get allowed. The SDK cannot install OS-level packages (e.g., ffmpeg, wkhtmltopdf). If your app relies on them, stick to a Dockerfile.

2. Force Chiseled Images: Update your .csproj. Add <ContainerFamily>resolute-chiseled</ContainerFamily> to halve your image size and eliminate shell-based CVE vectors.

3. Keep Manifest Commands: Don't trust the overwrite. Continue using docker manifest in your pipeline to aggregate the lightning-fast, QEMU-free linux-x64 and linux-arm64 SDK builds into a single tag.

4. Switch to Podman Agents: Zero-config rootless builds. Upgrade your self-hosted runners to Podman to immediately benefit from rootless container execution without updating build scripts.

Let’s be honest — moving from a single server to a cluster sounds simple on paper.
You just add a few more machines, right?
In practice, it’s the moment when small architectural mistakes start to grow legs.
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button.

1️⃣ Managing State the Right Way

Each request in a cluster might hit a different machine.
If your application keeps user sessions or cache in memory, that data probably won’t exist on the next node.
That’s why many teams decide to push state out of the app itself.

A few real-world tips:

• Keep sessions in Redis or something similar instead of local memory.
• Design endpoints so they don’t rely on earlier requests.
• Don’t assume the same server will handle two requests in a row — it rarely does.

2️⃣ Shared Files and Where to Put Them

Uploading files to local disk? That’s going to hurt in a cluster.
Other nodes can’t reach those files, and you’ll spend hours wondering why images disappear.

Better habits:

• Push uploads to S3, Azure Blob, or Google Cloud Storage.
• Send logs to a shared location instead of writing to local files.
• Keep environment configs in a central place so each node starts with the same settings.

3️⃣ Database Connections Aren’t Free

Every node opens its own database connections.
Ten nodes with twenty connections each — that’s already two hundred open sessions.
The database might not love that.

What helps:

• Put a cap on your connection pools.
• Avoid keeping transactions open for too long.
• Tune indexes and queries before scaling horizontally.

4️⃣ Logging and Observability Matter More Than You Think

When something breaks in a distributed system, it’s never obvious which server was responsible.
That’s why observability isn’t optional anymore.

Consider this:

• Stream logs to ELK, Datadog, or Grafana Loki.
• Add a trace ID to every incoming request and propagate it across services.
• Watch key metrics with Prometheus and visualize them in Grafana dashboards.

5️⃣ Background Jobs and Message Queues

If more than one node runs the same job, you might process the same data twice — or delete something by mistake.
You don’t want that kind of excitement in production.

A few precautions:

• Use a distributed lock or leader election system.
• Make jobs idempotent, so running them twice doesn’t break data.
• Centralize queue consumers or use a proper task scheduler.

Wrapping Up

Deploying to a cluster isn’t only about scaling up — it’s about staying stable when you do.
Systems that handle state, logging, and background work correctly tend to age gracefully.
Everything else eventually learns the hard way.

A cluster doesn’t fix design flaws — it magnifies them.

CI/CD (Continuous Integration / Continuous Delivery) is not just fancy tech talk - it's now a must-have for modern software teams.
Microsoft's Azure DevOps helps make these processes easier to manage.
But how do you create pipelines that work well for your team? Let's look at some practical tips that will make your life easier.

1. 📜 Define Your Pipeline as Code

Don't use the manual setup method that's hard to track. Azure DevOps lets you use YAML files for your pipelines, which gives you:

• A record of all changes - who made them and when
• The same setup across all environments
• The ability to undo changes when something goes wrong

This stops the common problem where something works on one computer but not another.

2. 🔑 Store Sensitive Information Safely

Never put passwords directly in your code, even temporarily.
Each environment should have its own settings, and keep sensitive information in Azure Key Vault or Library Variable Groups.

You'll avoid security problems later.

3. 🏗️ Keep Building and Releasing Separate

Think of Building like cooking a meal - you prepare everything and package it up.
Releasing is like delivering that meal to different people.

Keeping these as separate steps means:

• You create your package once, then send it to multiple places
• You save time and resources by not rebuilding the same thing over and over

4. 🧪 Add Automatic Testing

Don't waste time testing the same things manually over and over.
Set up different types of tests to run automatically. When tests run every time you make changes:

• You catch problems before your customers do
• Your software quality stays high without extra manual work

Azure DevOps has tools to help you see test results easily without searching through technical logs.

5. 🛡️ Add Safety Checks

Automatic doesn't mean pushing everything to your live system right away.
For important environments, add human approval steps or automatic checks like security scans.

This helps you avoid emergency problems in the middle of the night.

✅ Conclusion

Good Azure DevOps pipelines aren't just about automation - they help you feel confident in your process.
Remember these main points:

✔ Use YAML files to keep everything visible and trackable
✔ Keep passwords and sensitive data in secure storage (not in your code)
✔ Build once, deploy to many places
✔ Let automatic tests find problems before users do
✔ Add safety checks for important systems

In my previous article on Deploy Your ABP Framework MVC Project to Azure Container Apps, I talked about how ABP Mvc project can be easily deployed to Azure Container Apps. Now I will show how we can deploy to kubernetes environment, which looks a bit more complex but is more preferred for production, using a Helm chart.

Getting Started with ABP Framework Angular and Azure Kubernetes Service

To get started, you will need an ABP Framework Angular project that you want to deploy. If you don't have one, you can create a new project using the ABP CLI. You will also need an Azure subscription and an Azure Kubernetes Service.

Configuring Your ABP Framework Angular Project

We have a sample ABP Framework Angular project that we will use for this deployment. Before creating the Docker image and Helm chart, you just need to configure aspnet-core/src/***.HttpApi.Host/***.HttpApiHostModule.cs file to allow CORS requests from your frontend application. You can do this by updating the following code to the ConfigureServices method:

public override void ConfigureServices(ServiceConfigurationContext context)
    {
        var configuration = context.Services.GetConfiguration();
        var hostingEnvironment = context.Services.GetHostingEnvironment();

        if (!configuration.GetValue<bool>("App:DisablePII"))
        {
            Microsoft.IdentityModel.Logging.IdentityModelEventSource.ShowPII = true;
        }

        if (!configuration.GetValue<bool>("AuthServer:RequireHttpsMetadata"))
        {
            Configure<OpenIddictServerAspNetCoreOptions>(options =>
            {
                options.DisableTransportSecurityRequirement = true;
            });
        }
        context.Services.Configure<ForwardedHeadersOptions>(options =>
            {
                options.ForwardedHeaders = ForwardedHeaders.XForw

If your ABP Framework Angular project and Azure kubernetes cluster ready, we can start to build the docker images and pushing them to any container registry. In this article, I will use DockerHub as the container registry.

I will also show you how I automated the steps that I originally did manually to make it simpler in the beginning and then automated them in Azure Devops.

Creating a Docker Image for ABP Framework Angular

To create a Docker image for your ABP Framework Angular project, navigate to etc/build/build-images-locally.ps1 and fix the script to match your Docker Hub username and image name. Then, run the script to build the Docker image locally.

At the end of this process, check your Docker Hub repository to confirm that the image has been pushed successfully. My Docker Hub repository looks like this. Also you can use these my public images to test the deployment.

Creating Helm Chart for ABP Framework Angular

To deploy your ABP Framework Angular project to Azure Kubernetes Service, you need to create a Helm chart. Helm is a package manager for Kubernetes that allows you to define, install, and upgrade even the most complex Kubernetes applications. Helm uses a packaging format called charts, which are a collection of files that describe a related set of Kubernetes resources.

These helm charts are prepared to create a deployment, configmap, service and ingress for your ABP Framework Angular project. It is prepared not only for migration, frontend and backend, but also to create the sqlserver and redis that the application needs as a kubernetes service. If you already have redis and sqlserver, you don't need to stand them up in kubernetes, of course.

You can find the helm chart in the https://github.com/skoc10/k8s_works/tree/main/demo/helm/k8s/angular repository. You can configure the values-azure.yaml file according to your needs.

Deploying to Azure Kubernetes Service

Note: You need to have nginx-ingress-controller and cert-manager installed for letsencrypt certificate in your kubernetes cluster.

Now that you have Docker images for your ABP Framework Angular project and a Helm chart, you can proceed to deploy it to Azure Kubernetes Service. To do this, you need to create a new Azure Kubernetes Service resource and configure the values-azure.yaml file according to your needs. If you want, you can deploy a single Helm with demo/helm/k8s/deploy-staging.ps1 script you can deploy each chart separately.

After deploying the Helm chart, you can check the deployment status to confirm that the deployment was successful. You can also check the logs of the pods to see if there are any errors.

Finally, you can navigate to the web url to see your ABP Framework Angular project running in Azure Kubernetes Service.

CI/CD with Azure DevOps

I have automated the steps that I originally did manually to make it simpler in the beginning and then automated them in Azure Devops. You can find the azure-pipelines.yml file in the https://github.com/skoc10/k8s_works/blob/main/demo/azure/azure-pipelines.yml repository. You can configure the azure-pipelines.yml file according to your needs.

trigger:
  tags:
    include:
      - "*.*.*"

variables:
  dockerRegistryServiceConnection: 'demo-reg'
  buildContextBasePath: '$(Build.SourcesDirectory)'
  tag: $(Build.BuildNumber)
  DOCKER_BUILDKIT: 1

pool:
  name: ubuntu

stages:
- stage: Build
  displayName: Build
  jobs:
  - job: CheckChanges
    displayName: Check if Angular or ASP.NET Core has changed
    pool:
      name: ubuntu
    steps:
    - checkout: self

# Migration
    - task: Docker@2
      displayName: 'Build Migration Docker image'
      inputs:
        command: build
        repository: demo-angular-apppro/migration
        dockerfile: $(buildContextBasePath)/aspnet-core/src/Demo.AzureAppsAngular.DbMigrator/Dockerfile.azure
        buildContext: $(buildContextBasePath)/aspnet-core
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - task: Docker@2
      displayName: 'Push Migration Docker image'
      inputs:
        command: push
        repository: demo-angular-apppro/migration
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - task: HelmDeploy@0
      displayName: 'Delete Migrator'
      inputs:
        connectionType: Kubernetes Service Connection
        kubernetesServiceConnection: 'aks-demoms'
        namespace: 'angular'
        command: delete
        arguments: dbmigrator
      continueOnError: true

    - task: HelmDeploy@0
      displayName: 'Deploy Migration to AKS'
      inputs:
        connectionType: Kubernetes Service Connection
        kubernetesServiceConnection: 'aks-demoms'
        namespace: 'angular'
        command: 'upgrade'
        chartType: 'FilePath'
        chartPath: '$(buildContextBasePath)/aspnet-core/etc/k8s/angular/charts/dbmigrator'
        releaseName: 'dbmigrator'
        overrideValues: 'image.tag=$(tag)'
        valueFile: '$(buildContextBasePath)/aspnet-core/etc/k8s/angular/charts/dbmigrator/values.yaml'
        waitForExecution: false

# Backend
    - task: Docker@2
      displayName: 'Build Backend Docker image'
      inputs:
        command: build
        repository: demo-angular-apppro/backend
        dockerfile: $(buildContextBasePath)/aspnet-core/src/Demo.AzureAppsAngular.HttpApi.Host/Dockerfile.azure
        buildContext: $(buildContextBasePath)/aspnet-core
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - task: Docker@2
      displayName: 'Push Backend Docker image'
      inputs:
        command: push
        repository: demo-angular-apppro/backend
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - task: HelmDeploy@0
      displayName: 'Deploy Backend to AKS'
      inputs:
        connectionType: Kubernetes Service Connection
        kubernetesServiceConnection: 'aks-demoms'
        namespace: 'angular'
        command: 'upgrade'
        chartType: 'FilePath'
        chartPath: '$(buildContextBasePath)/aspnet-core/etc/k8s/angular/charts/backend'
        releaseName: 'backend'
        overrideValues: 'image.tag=$(tag)'
        valueFile: '$(buildContextBasePath)/aspnet-core/etc/k8s/angular/charts/backend/values.yaml'
        waitForExecution: false

# Frontend
    - task: Docker@2
      displayName: 'Build Frontend Docker image'
      inputs:
        command: build
        repository: demo-angular-apppro/frontend
        dockerfile: $(buildContextBasePath)/angular/Dockerfile.azure
        buildContext: $(buildContextBasePath)/angular
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - task: Docker@2
      displayName: 'Push Frontend Docker image'
      inputs:
        command: push
        repository: demo-angular-apppro/frontend
        containerRegistry: $(dockerRegistryServiceConnection)
        tags: |
          $(tag)

    - task: HelmDeploy@0
      displayName: 'Deploy Frontend to AKS'
      inputs:
        connectionType: Kubernetes Service Connection
        kubernetesServiceConnection: 'aks-demoms'
        namespace: 'angular'
        command: 'upgrade'
        chartType: 'FilePath'
        chartPath: '$(buildContextBasePath)/aspnet-core/etc/k8s/angular/charts/angular'
        releaseName: 'frontend'
        overrideValues: 'image.tag=$(tag)'
        valueFile: '$(buildContextBasePath)/aspnet-core/etc/k8s/angular/charts/angular/values.yaml'
        waitForExecution: false

Conclusion

In this article, I showed you how you can deploy your ABP Framework Angular project to Azure Kubernetes Service using Helm chart. I also showed you how you can automate the deployment process using Azure DevOps. I hope you found this article helpful. If you have any questions or feedback, please feel free to leave a comment below.

In this article, we will show the seamless deployment of an ABP Framework MVC project to Azure Container Apps. enabling you to deploy and run containerized applications without the hassle of managing the infrastructure underneath. It provides an uncomplicated and cost-effective method for deploying and scaling your applications.

Getting Started with ABP Framework MVC and Azure Container Apps

To get started, you will need an ABP Framework MVC project that you want to deploy. If you don't have one, you can create a new project using the ABP CLI. You will also need an Azure subscription and an Azure SQL database.

Before creating Azure container apps resources and deploying the ABP Framework MVC project, I show you how you can effortlessly create Docker images and push them to Docker Hub, leveraging the pre-configured Docker file and scripts that come with the ABP MVC framework.

Creating a Docker Image for ABP Framework MVC

To create a Docker image for your ABP Framework MVC project, navigate to etc/build/build-images-locally.ps1 and fix the script to match your Docker Hub username and image name. Then, run the script to build the Docker image locally.

Next, check the Docker Hub repository to confirm that the image has been pushed successfully.

Deploying to Azure Container Apps

Now that you have Docker images for your ABP Framework MVC project, you can proceed to deploy it to Azure Container Apps. To do this, navigate to the Azure portal and create a new Azure Container Apps resource. Ypu will not need just an Azure Container Apps resource, but also an Azure Container Apps Job resource to migrate the database schema and seed data for your ABP Framework MVC project.

Step 1: Deploy the Docker Image

Firstly, create a new Azure Container Apps resource without environment variables. You will need web url so that you can set it as an environment variable in the next step. Then, check the deployment status to confirm that the deployment was successful.

Step 2: Migrate Database Schema and Seed Data

Secondly, create a new Azure Container Apps Job resource to migrate the database schema and seed data. You can do this by creating a new job with the following environment variables:

ConnectionStrings__Default - Server=tcp:demoabpapp.database.windows.net,1433;Initial Catalog=mvcapppro;Persist Security Info=False;User ID=demoapppro;Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

OpenIddict__Applications__mvcapppro_Web__RootUrl - https://mvcwebapp.victoriousgrass-8b06438d.northeurope.azurecontainerapps.io

To get ConnectionStrings of Sql Database and url of the web app, you can navigate to the Azure portal and check the properties of the Azure SQL database and Azure Container Apps resource.

Finally, check the job status to confirm that the database migration and seeding were successful. You can connect to the Azure SQL database to verify that the schema and seed data have been applied.

Step 3: Edit the Azure Container Apps Resource

After completing these steps, you have to edit the Azure Container Apps resource to add the required environment variables for your ABP Framework MVC project. You can do this by adding the following environment variables:

App__SelfUrl - https://mvcwebapp.victoriousgrass-8b06438d.northeurope.azurecontainerapps.io

ASPNETCORE_URLS - http://+:80

AuthServer__Authority - https://mvcwebapp.victoriousgrass-8b06438d.northeurope.azurecontainerapps.io

ConnectionStrings__Default - Server=tcp:demoabpapp.database.windows.net,1433;Initial Catalog=mvcapppro;Persist Security Info=False;User ID=demoapppro;Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

Step 4: Create a New Deployment

Once you have added the environment variables, save and create a new deployment to apply the changes. You can now access your ABP Framework MVC project running on Azure Container Apps by navigating to the URL provided in the environment variables.

You can see the Azure resources created for the ABP Framework MVC project deployment that includes the Azure Container Apps resource, Azure Container Apps Job resource, and Azure SQL database.

Conclusion

Azure Container Apps provides a simple and cost-effective way to deploy and scale your ABP Framework MVC projects without managing the underlying infrastructure. By following the steps outlined in this article, you can seamlessly deploy your ABP Framework MVC projects to Azure Container Apps and enjoy the benefits it offers.

I hope you found this article helpful. If you have any questions or feedback, please feel free to leave a comment below.

Introduction

In today's digital world, providing reliable and transparent information about your platform's availability is essential to maintaining trust among your community and customers. With the growing number of abp.io users, we needed a dedicated status page status.abp.io to keep everyone informed about our platform's health. To achieve this, we utilized the open-source project Upptime and built a custom status page on GitHub Pages. In this article, we'll guide you through the process of creating our own status page and customizing it to suit our needs.

Why we chose Upptime

Upptime is an open-source, easy-to-use, and cost-effective solution for monitoring websites and APIs. It offers essential features, such as downtime alerts, response time monitoring, and status history. We decided to use Upptime because of its compatibility with GitHub Pages, ease of customization, comprehensive documentation and discord notifications.

Advantages of Upptime

• Open-source: Allows easy customization and community support.

• GitHub Pages compatibility: Seamless integration with GitHub Pages for hosting.

• Cost-effective: Utilizes GitHub Actions, which provides free monitoring within the GitHub Actions usage limits.

• Comprehensive documentation: Easy-to-follow instructions for setting up and customizing the status page.

Disadvantages of Upptime

• Limited monitoring capabilities: Upptime offers basic monitoring features but lacks advanced capabilities found in dedicated monitoring tools.

• Dependence on GitHub Actions: Upptime relies on GitHub Actions, which may pose limitations for users unfamiliar with GitHub's ecosystem or those with large-scale projects.

• No built-in alerting system: Users must rely on third-party integrations or custom solutions for notifications, requiring additional configuration.

• Limited customization options: Upptime allows for some customization, but options are limited compared to comprehensive monitoring platforms.

• Self-hosted limitations: As a self-hosted solution, users are responsible for maintaining and managing their own infrastructure, which may not be ideal for those who prefer a fully managed monitoring solution.

How to set up the status page on GitHub Pages

To get started with our custom status page, we followed the instructions in the Upptime documentation. Here's a summary of the steps we took:

• Fork the Upptime template repository to our own GitHub account as abpio-status.

• Configure the GitHub Actions workflow. We configured the GitHub Actions workflow by adding the following lines to the .github/workflows/uptime.yml

• Add the monitored endpoints. We added the monitored endpoints (our abp.io websites) to the .upptimerc.yml file. This file is located in the root of the repository and contains a list of URLs that Upptime monitors.

sites:

  - name: abp.io

    url: https://abp.io/health-status

  - name: community.abp.io

    url: https://community.abp.io/health-status

  - name: commercial.abp.io

    url: https://commercial.abp.io/health-status

  - name: nuget.abp.io

    url: https://nuget.abp.io/health-status

  - name: docs.abp.io

    url: https://docs.abp.io/health-status

  - name: support.abp.io

    url: https://support.abp.io/health-status

  - name: blog.abp.io

    url: https://blog.abp.io/health-status

  - name: commercial-demo.abp.io

    url: https://commercial-demo.abp.io/health-status

• Enable GitHub Pages. Finally, we enabled GitHub Pages for our forked repository by going to the repository's settings and selecting the gh-pages branch as the source. This made our status page accessible at status.abp.io.

Customizing the status page

After setting up the default Upptime status page, we focused on customizing it to align with our brand and provide a consistent experience for our community and customers. We made the following changes:

• Updating the logo and favicon. We replaced the default logo and favicon with our own abp.io branded assets. This involved adding the new image files to the repository and updating the references in the .upptimerc.yml file:

• Customizing the color scheme and typography. We customized the color scheme and typography to match our corporate identity by editing the .upptimerc.yml file:

status-website:

  theme: dark

  # Add your custom domain name, or remove the `cname` line if you don't have a domain

  # Uncomment the `baseUrl` line if you don't have a custom domain and add your repo name there

  cname: status.abp.io

  # baseUrl: /abpio-status

  logoUrl: https://commercial.abp.io/assets/svg/abp-logo-light.svg

  favicon: https://raw.githubusercontent.com/abpframework/abpio-status/master/assets/abp-logo-without-text.svg

  faviconSvg: https://raw.githubusercontent.com/abpframework/abpio-status/master/assets/abp-logo-without-text.svg

Creating GitHub Issues for Maintenance Information on status.abp.io

To provide maintenance information for your status page, you can create GitHub issues in your repository. This allows you to inform your users about planned downtime or ongoing maintenance work.

Discord Notifications

Create a Discord Webhook

To set up Discord notifications for your status.abp.io status page using Upptime documentation, follow these steps:

• In Discord, go to "Server Settings" > "Integrations" > "Create Webhook."

• Customize the Webhook name, choose a channel, and copy the Webhook URL.

Configure GitHub Actions

• In your Upptime repository, go to the "Settings" tab.

• Click on "Secrets" and then "New repository secret."

• Add secret: Name it DISCORD_WEBHOOK_URL and paste the Webhook URL as the value.

• Add environment variables NOTIFICATION_DISCORD_WEBHOOK and NOTIFICATION_DISCORD set it to true.

Your status page will now send notifications to your Discord channel whenever there's a change in your platform's status.

Conclusion

If your primary goal is to create a simple, cost-effective status page with basic monitoring features, Upptime is an excellent choice. Its open-source nature, seamless integration with GitHub Pages, and comprehensive documentation make it a user-friendly option.

If you require advanced monitoring capabilities or prefer a fully managed monitoring solution, you may want to explore dedicated monitoring tools, such as Pingdom, Uptime Robot, or Datadog. These tools typically offer more robust monitoring features, built-in alerting systems, and customizable dashboards.

Creating a custom status page for abp.io using Upptime and GitHub Pages proved to be an efficient and cost-effective solution. By following the documentation and customizing the template, we were able to provide our community and customers with a reliable source of information about our platform's availability. With this new status page status.abp.io, we can continue to build trust and transparency as our platform grows and evolves.

On-Premise Server: The old platform

There were several reasons for migrating from the old on-premise platform to Azure. First, the Kubernetes cluster and the database were on the same Windows server. Additionally, the Linux virtual machines in Kubernetes were on the Windows server and had limited resources. Furthermore, the Kubernetes maintenance was quite challenging, which was another reason for the migration.

Reasons for Moving to Azure: The new platform

The decision to move to the cloud was made to eliminate the disadvantages of the old platform. The migration to Azure meant that the resources would be independent of each other but faster in terms of communicating with each other. The platform would also take advantage of cloud security and availability. The managed Kubernetes service that Azure offers comes with autoscaling and loadbalancing, which makes the platform more reliable. Finally, the migration to Azure would provide a better quality service to global customers and the community.

Before Moving to Azure

Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure.You can check the details of database migration from this article Migrating from MS-SQL to Postgresql.

The platform was tested in a staging environment created on Azure with the same resources as the production environment. The staging environment was used to test and optimize the migration process, including the migration of data from the old platform to Azure, which was tested multiple times to ensure success.

Creating and Configuring the abp.io Platform on Azure

Several steps were taken to create and configure the abp.io platform on Azure. Terraform was used to create the infrastructure (VM, Private Network, AKS, Postgresql Flexible Server...), while Ansible was used to configure the Azure resources like Terraform, Helm, Kubectl, Docker, VPN, Redis, Prometheus, Grafana, ElasticSearch, Kibana and so on.... Azure DevOps pipelines and release were used for AKS deployment. The most time-consuming part in this process was to prepare, test and optimize the terraform and ansible settings files.

To access our platform, which is configured on a private network in Azure, we require a VPN connection. To enable this, we have installed Wireguard - an open source VPN service - by creating a virtual machine using Terraform and configuring it with Ansible in Azure. This approach has made the process efficient and streamlined.

The most important step was to transfer the data in both the database and Kubernetes of the volumes. rsync (remote sync commands) were used to transfer the data from Kubernetes volumes to Azure Files through the VPN machine. Additionally, pg_dump and pg_restore were used to transfer the PostgreSQL database through the machine with VPN.

Before the production environment, the data migration was tested many times for the staging environment. We estimated this migration to take max 1.5 hours. The ABP community was informed that there may be interruptions during the hours designated for the transition to Azure. To inform our customers and community, we created a status page before this migration. The new status page is status.abp.io. From now on we will make all the infrastructural announcements on status.abp.io. We used Upptime which is an open-source uptime monitor and status page provider. During the migration of the production environment, the websites and databases were still up and running. After the data transfer, the only remaining step was to direct the traffic of the already standing abp.io sites to the Azure Kubernetes service via Cloudflare.

We would like to happily state that we were offline for only 4 minutes during this transition.

Benefits of Moving to Azure

The migration to Azure resulted in several benefits. The platform is now more reliable, scalable, secure, solid with built-in one-click backup and recovery capabilities for abp.io. Additionally, the critical resources are in a private network, making them more secure than the old environment. When we initially compared the speed of our abp.io sites before and after migrating to Azure, we were pleasantly surprised by the significant improvement in performance. To be honest, we did not expect such a speed increase.

In conclusion, migrating a Kubernetes platform with a database from on-premise to Azure is a complex process that requires careful planning and execution. However, the benefits gained from the migration make the process worthwhile. By moving to Azure, the abp.io platform now has a more reliable and available infrastructure that is more secure than the old environment. The migration also resulted in significant improvements in connection speeds, which ultimately provides a better service to global customers and the community.

Database migration is a common practice for organizations that want to move from one database system to another. This can be for various reasons, including cost, performance, and features. In this article, we will discuss migrating a database from MS-SQL to PostgreSQL, the challenges that may arise during the migration, and how to overcome them. And we recently moved the main database of the https://abp.io platform from MS-SQL to PostgreSQL.

We switched our database from Microsoft SQL Server (MS-SQL) to PostgreSQL to move our on-premise platform to Azure. We’ve also discovered that the license cost for MS-SQL on Azure was significantly higher than PostgreSQL. After conducting a cost-benefit analysis, we migrated our database to PostgreSQL to save costs.

Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This allowed us to test and fine-tune the migration process before making the final switch to Azure.

Challenges

Despite using a third-party tool(DBConvert for MySQL & PostgreSQL) for the migration, we faced three main problems when exporting data to PostgreSQL. Firstly, some tables with plain text had

UTF-8 encoding problems. We overcame this problem by dump-restoring these tables.

Secondly, our database had to be case-insensitive, but PostgreSQL does not have this as a default configuration. We handled it using citext with the ABP migration service.

While everything was proceeding very smoothly, we faced one last problem: importing binary data, such as the content of the NuGet packages. It was hard to understand that the binaries of the NuGet packages were different. Our paid commercial NuGet packages are stored as binary data in the database. Therefore, it was the most compelling part of this migration to transfer the NuGet packages. Fortunately, we overcame the binary error. And we decided to write a custom .NET tool to move only the binary data from MS-SQL to PostgreSQL, thanks to the ABP Core team!

Conclusion

One of the benefits of using PostgreSQL is the low license costs of the Azure platform. As the main contributors of ABP, we also use ABP Framework under the hood of our abp.io websites; we could easily switch to PostgreSQL. For those who want to switch their ABP project to PostgreSQL, check out docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL. We had not used any MS-SQL specific function, therefore there was no need to make any changes in the repository classes. This means that the applications that were previously using MS-SQL can seamlessly switch to PostgreSQL without any modifications.

Thanks to the flexibility of ABP, it has PostgreSQL package, which is 100% compatible with PostgreSQL. This helped us to make this migration very smooth and seamless.

In conclusion, migrating a database from MS-SQL to PostgreSQL can be challenging, but it can bring significant cost savings in the long run. By testing and fine-tuning the migration process before making the final switch, we overcame the challenges we’d faced during the migration process. Thanks to the flexibility of ABP, we were able to make the transition with minimal code changes. Also, we didn't see any big performance differences between MS-SQL and PostgreSQL.