Indonesia's PDN (Pusat Data Nasional): What Developers Need to Know About Government Cloud Migration

Indonesia's Pusat Data Nasional (PDN) is the government's most ambitious digital infrastructure initiative. Presidential Regulation No. 95/2018 on SPBE (Sistem Pemerintahan Berbasis Elektronik) defines it as a set of interconnected data centres shared by central and regional agencies, and when construction began in Cikarang in November 2022 the then minister said it would consolidate government data spread across about 2,700 data centres and servers. For developers building systems for government agencies, understanding PDN's architecture, compliance requirements, and migration process is not optional, because the same regulation requires every central and regional agency to use it.

PDN Architecture and Regional Hub Locations

The PDN program was planned as several facilities rather than one building, so that agencies across Indonesia could be served while their data stays under Indonesian jurisdiction. Perpres 95/2018 requires each PDN facility to meet the Indonesian national standard (SNI) for data centre design and management, and to obtain an operational feasibility opinion from the communications minister and a security feasibility opinion from the head of the national cyber security agency, BSSN.

The Planned PDN Locations

The 2022 plan named four sites: Cikarang in Kabupaten Bekasi (West Java), Batam (Riau Islands), Ibu Kota Nusantara (East Kalimantan) and Labuan Bajo (East Nusa Tenggara). The plan has since narrowed. In February 2025 Antara reported that the Batam project had been stopped and that the IKN and Labuan Bajo projects had not yet reached tender. The only facility in service is PDN 1, the Cikarang site, managed by Komdigi's Balai Layanan PDN in Kabupaten Bekasi. It was cleared on 14 January 2026 for limited operation with low-risk services only, after BSSN security testing from July to December 2025.

Government Cloud Services Within PDN

PDN offers IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) tiers exclusively for government agencies. Services include virtual machine instances, managed Kubernetes clusters, managed databases (PostgreSQL, MySQL), object storage, and load balancers — all hosted within Indonesian jurisdiction. Commercial cloud providers (AWS, Azure, GCP) may be used for non-classified workloads, but data classified as RAHASIA or above must remain within PDN infrastructure.

Regulatory Framework: Perpres 95/2018 and PP No. 71/2019

The PDN rests on Presidential Regulation No. 95/2018 on SPBE, not on PP No. 71/2019. Article 27 makes the PDN part of the national SPBE infrastructure, defined as a set of data centres shared by central and regional agencies and connected to each other, and Article 30 requires every central and regional agency to use it. PP No. 71/2019 on the Implementation of Electronic Systems and Transactions supplies the location rule underneath: Article 20 requires public-scope electronic systems and data to be managed, processed and stored in Indonesia unless the storage technology is unavailable domestically, and it never names the PDN. Permenkomdigi 18/2025, which created the Balai Layanan PDN to run it, cites the SPBE regulation as its mandate. SPBE further requires interoperability between all agency systems via standardized APIs and shared services.

Data Classification Under PDN Security Tiers

PDN enforces four security classification tiers based on Indonesian government standards: TERBUKA (open — publicly accessible data), TERBATAS (limited — internal government use only), RAHASIA (confidential — restricted access, requires encryption at rest and in transit), and SANGAT RAHASIA (top secret — highest protection, only accessible within PDN Tier 1 secure zones). Misclassifying data at a lower tier than required constitutes a compliance violation subject to administrative sanctions.

# terraform/pdn-government-workload/main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# PDN-compliant: all resources must be in approved Indonesian regions
provider "aws" {
  region = var.pdn_region  # e.g. "ap-southeast-3" (Jakarta)
}

# Enforce encryption at rest — mandatory for SPBE Tier 2+
resource "aws_s3_bucket" "gov_data" {
  bucket = "${var.agency_code}-pdn-data"
  tags = {
    Classification = "RAHASIA"        # TERBUKA / TERBATAS / RAHASIA / SANGAT_RAHASIA
    DataOwner      = var.agency_code
    SPBECompliant  = "true"
    Regulation     = "PP-71-2019"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "gov_data_enc" {
  bucket = aws_s3_bucket.gov_data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
      kms_master_key_id = aws_kms_key.pdn_key.arn
    }
  }
}

resource "aws_kms_key" "pdn_key" {
  description             = "PDN encryption key — ${var.agency_code}"
  deletion_window_in_days = 30
  enable_key_rotation     = true
  tags = {
    Regulation = "PP-71-2019"
  }
}

# Block all public access — no public buckets allowed for government data
resource "aws_s3_bucket_public_access_block" "gov_data_block" {
  bucket                  = aws_s3_bucket.gov_data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Practical Migration Checklist for Developers

Before migrating to PDN, developers must complete: (1) data inventory and classification audit for all datasets; (2) dependency mapping of external services and APIs; (3) network connectivity plan (IPSec VPN or dedicated MPLS to PDN); (4) a disaster recovery strategy that does not assume a second PDN site, since only PDN 1 is operating; (5) BSSN security assessment for RAHASIA-tier workloads; and (6) SPBE integration test for API interoperability with national shared services (identity, payment, document management).

Infrastructure as Code for PDN-Compliant Workloads

Terraform and cloud-init scripts should encode PDN compliance requirements as immutable infrastructure constraints — not as manual post-deployment steps. This ensures every deployment is auditable, reproducible, and compliant by default. The Terraform snippet below demonstrates S3-compatible object storage provisioning on PDN's cloud infrastructure with mandatory encryption, public access blocking, and compliance tags.

Encryption at Rest and in Transit Requirements

All workloads on PDN must encrypt data at rest using AES-256 with agency-managed keys stored in PDN's HSM (Hardware Security Module) service. TLS 1.2 or above is mandatory for all in-transit data. Unencrypted HTTP endpoints are not permitted for any TERBATAS or higher classification workloads — this must be enforced at the load balancer level, not left to application code.

SPBE Integration: Connecting to National Shared Services

SPBE mandates that government applications connect to national shared service APIs rather than building redundant infrastructure. These include: DUKCAPIL API for NIK verification, SATU SEHAT API for health data exchange, BRImo/GovPay for government payment collection, and the National Single Sign-On (SSO) via SPBE Identity. Integration requires registering your application in the SPBE app catalogue and completing an interoperability assessment.

Network Segmentation and VPC Design on PDN

PDN tenants receive isolated virtual networks (equivalent to AWS VPCs) with no default internet egress. Internet connectivity is provided via a government-managed NAT Gateway with IP allowlisting. Design your VPC with at least three subnets: a public DMZ subnet for load balancers, a private application subnet for compute, and an isolated data subnet for databases — with all database traffic restricted to the application subnet via security group rules.

Monitoring and Audit Logging Compliance

PP No. 71/2019 Article 22 requires every electronic system operator to keep an audit trail of all system activity, for supervision, law enforcement, dispute resolution, verification and examination. It sets no retention period, so take the retention figure from your agency's records policy and write it into the design. Integrate the platform's audit logging from day one. All privileged administrative actions, data access events, and configuration changes must be immutably logged. Export logs daily to a write-once storage bucket to prevent tampering.

Lessons Learned and Next Steps

There is no migration wave to learn from yet: PDN 1 was cleared only on 14 January 2026, for low-risk services, and higher-risk services wait for ISO certification and BSSN's recommendations. The clearest lesson so far comes from the temporary national data centre. In June 2024 Brain Cipher ransomware encrypted the data in PDNS 2, the temporary facility in Surabaya run under a 2024 tender by a partnership that included Telkom, and Telkom's disclosure to OJK counted 239 affected tenants as of 26 June. Keep a restorable copy of agency data outside the platform, test network latency, VPN tunnels and storage performance before cutover, and engage early with BSSN and Komdigi's PDN team.

DevSecOps Pipeline Adaptations for PDN

Government workloads on PDN require security scanning at every CI/CD pipeline stage: SAST (Static Application Security Testing) to detect vulnerabilities before build, SCA (Software Composition Analysis) to identify vulnerable dependencies, container image scanning before pushing to PDN's private registry, and IaC security scanning (tfsec, checkov) to flag non-compliant Terraform configurations. BSSN may request pipeline audit logs during security assessments.

Key terms in this article include PDN, SPBE, PP 71/2019, and Government Cloud.

Related Articles

• Infrastructure as Code with Terraform
• DevSecOps: Building a Secure CI/CD Pipeline