01 / A starting point

Abraham Naiborhu

Application Engineer · JakartaCloud · Platform · DevOps
Portrait of Abraham Naiborhu

I like making things
work together.

Preparing portfolio…

Application experienceSelected product work

I build applications that keep working when part of them fails.

My role: end-to-end engineering, from design and development to deployment and monitoring.

Sattabi · Door access

I built all of it, from the door wiring to the app.

  1. A tap. A check. An open door.
  2. The cloud connection drops.
  3. The connection dropped. Authorized access didn’t.
ControllerCloudOFFLINEReaderAllowed locally

Sattabi · Door access

I built all of it, from the door wiring to the app.

Visit Sattabi

  1. ControllerCloudOFFLINEReaderAllowed locally

    A tap. A check. An open door.

  2. ControllerCloudOFFLINEReaderAllowed locally

    The cloud connection drops.

  3. ControllerCloudOFFLINEReaderAllowed locally

    The connection dropped. Authorized access didn’t.

AVAD · Worship presentation

Full-stack developer.

  1. One operator. Every screen in step.
  2. One screen loses its connection.
  3. It reconnects. The room is back in sync.
DISPLAY / B010203RECONNECTINGLIVE / DISPLAY A010203OPERATOR010203

AVAD · Worship presentation

Full-stack developer.

Visit AVAD

  1. DISPLAY / B010203RECONNECTINGLIVE / DISPLAY A010203OPERATOR010203

    One operator. Every screen in step.

  2. DISPLAY / B010203RECONNECTINGLIVE / DISPLAY A010203OPERATOR010203

    One screen loses its connection.

  3. DISPLAY / B010203RECONNECTINGLIVE / DISPLAY A010203OPERATOR010203

    It reconnects. The room is back in sync.

Glinsta · Google Workspace for business

Full-stack developer.

  1. One payment starts the account setup.
  2. Setup fails halfway. The work isn’t lost.
  3. Retry safely. Exactly one account.
PAYMENT RECEIVEDPAID.ACCOUNT SETUPWORKSPACE ACCOUNTONE PAYMENT. ONE ACCOUNT.RETRY SAFELY

Glinsta · Google Workspace for business

Full-stack developer.

Visit Glinsta

  1. PAYMENT RECEIVEDPAID.ACCOUNT SETUPWORKSPACE ACCOUNTONE PAYMENT. ONE ACCOUNT.RETRY SAFELY

    One payment starts the account setup.

  2. PAYMENT RECEIVEDPAID.ACCOUNT SETUPWORKSPACE ACCOUNTONE PAYMENT. ONE ACCOUNT.RETRY SAFELY

    Setup fails halfway. The work isn’t lost.

  3. PAYMENT RECEIVEDPAID.ACCOUNT SETUPWORKSPACE ACCOUNTONE PAYMENT. ONE ACCOUNT.RETRY SAFELY

    Retry safely. Exactly one account.

Continue to the platform story

01 / THE RESPONSIBILITY GROWS

I build applications and the systems that support them. Deployment, runtime and monitoring become a shared platform for the team.

From applications to platform engineering

I design, build, deploy and monitor applications. That experience led me to build a shared development and staging platform for the team.

This is a conceptual illustration of my responsibilities, rather than a diagram of where these products are hosted.

The starting pointOn premises · Development and staging

The team needed
a better way to ship.

Every application meant another manual deployment. I wanted to give the team a shared way to deploy and understand their applications, starting with development and staging.

ssh server git pull pm2 restart

  1. Every deploy was by hand. When something broke, it simply broke.
  2. I replaced the routine with a platform, one problem at a time.
  3. One problem is still open, and I’m working on it.
  1. ManualA push triggers checks, a build and a versioned deploy
  2. Easy to breakEvery change is checked and built the same way; the recorded version keeps running
  3. InvisibleMetrics, logs and alerts
  4. Couldn’t growThe main internal app’s workers scale to more copies
  5. No fallbackIn progressBackup and restore validation; a separate backup destination is planned

ssh server git pull pm2 restart

One problem is still open, and I’m working on it.

  1. ManualA push triggers checks, a build and a versioned deploy
  2. Easy to breakEvery change is checked and built the same way; the recorded version keeps running
  3. InvisibleMetrics, logs and alerts
  4. Couldn’t growThe main internal app’s workers scale to more copies
  5. No fallbackIn progressBackup and restore validation; a separate backup destination is planned
A platform for the teamOn premises · Non-production

Then I built
a place for
our applications.

HardwareNetworkingDeliveryObservabilityDeveloper onboarding

A developer’s change

From source to running software.

A developer’s change becomes a deployed, observed applicationSource changes go through checks and a container build. The image version is recorded in deployment configuration, which Argo CD reconciles into Kubernetes. Metrics, logs and alerts provide visibility into running workloads. Source changeDeveloper · GitCheck + buildCI · Container imageRecord + reconcileVersioned config · Argo CDRun the applicationKubernetesMetrics · Logs · Alerts
  1. Source change Developer
  2. Check + build Container image
  3. Record + reconcile Versioned config · Argo CD
  4. Run the application Kubernetes
  5. Observe Metrics · Logs · Alerts
From source change to running application and operational visibility.

A developer pushes a change. CI checks it and builds a container image tagged with the commit SHA. The deployment repository records that version; Argo CD reconciles it into the cluster. Metrics, logs and alerts provide visibility into the running application.

  1. A developer pushes a change to the application repository.
  2. CI checks the change and builds a container image tagged with its commit SHA.
  3. The deployment repository records that version. Argo CD reconciles the declared state.
  4. Kubernetes runs the application. Metrics, logs and alerts provide operational visibility.
  5. I built the shared foundation and onboarded my peers’ applications, starting with development and staging.
Inside the platform Technical detail
Foundation and networking
Linux hosts, containerd and a kubeadm cluster, with Calico networking and network policies. MetalLB provides load-balancer addresses on the local network.
Application access
Cloudflare Tunnel connects public access to Envoy Gateway. Gateway API routes requests; cert-manager manages origin certificates.
Delivery and onboarding
GitHub Actions checks and builds container images tagged with the commit SHA. Kustomize describes environment configuration; Argo CD reconciles the declared state. I also help developers prepare their applications for container delivery.
Data and persistence
PostgreSQL runs with persistent storage backed by NFS. The current design has a single database writer and shared storage dependencies.
Operational visibility
Prometheus and Grafana provide metrics and dashboards. Alloy and Loki collect logs; Alertmanager routes operational notifications.

Current non-production design · Backup and restore validation is ongoing; a separate backup destination is planned.

Current scope
Applications and developers in the current development and staging environment.

10applications
~11developers
Engineering judgmentReliability within constraints

I keep asking:
what if this fails?

High availability has a cost. I look for practical ways to keep essential behavior working, and separate a working fallback from recovery that still needs proof.

When the normal path fails

Conceptual example · Sattabi local access

PRIMARY PATH LOSTREQUESTACCESSWAITINGLOCAL AUTHORIZATIONSATTABI / IMPLEMENTED FALLBACK
  1. PRIMARY PATH LOSTREQUESTACCESSWAITINGLOCAL AUTHORIZATIONSATTABI / IMPLEMENTED FALLBACK

    First, understand the failure.

  2. PRIMARY PATH LOSTREQUESTACCESSWAITINGLOCAL AUTHORIZATIONSATTABI / IMPLEMENTED FALLBACK

    The primary path stops. Hold that thought.

  3. PRIMARY PATH LOSTREQUESTACCESSWAITINGLOCAL AUTHORIZATIONSATTABI / IMPLEMENTED FALLBACK

    A local fallback keeps access moving.

A fallback is only useful when we know its limits.

01 / Keep working

Preserve the essential action.

Sattabi keeps a local copy of who may enter, so authorized access can continue when the cloud connection drops.

02 / Know the limits

Name the remaining dependencies.

My current development and staging platform has a single database writer and shared storage dependencies. Those remain constraints in its recovery design.

03 / Prove recovery

Validate before claiming resilience.

On the platform, that question is still open: backup and restore validation is ongoing, and a separate backup destination is planned.

Continue to the next team
The next teamAbraham Naiborhu · Jakarta

I like making things work together.

What could
we build
together?

Cloud Engineer / Platform Engineer / DevOps Engineer

I bring an application developer’s perspective to the infrastructure and delivery systems that support the work. If that fits your team, let’s talk.

Evidence

More of the work, if you want depth.

Public engineering work

The decisions behind the implementation.

Public cloud projects and writing provide another way to explore my work.

01 / Infrastructure foundation

GCP Terraform Foundation

A reusable infrastructure foundation.

One decision

Separated state-bucket bootstrap from the foundation that consumes it.

02 / Controlled delivery

Keyless CI/CD on Google Cloud

Short-lived access instead of static credentials.

One decision

Separated manual apply into a fresh planning job and an environment-gated execution job.

03 / Private compute, public entry

Production-Lite GCP Web Platform

Private compute. A deliberate public entry.

One decision

Kept application VMs without external IP addresses, behind an external load balancer.

01 / 03
Continue to the implementation notes

Implementation notes

GCP Terraform Foundation

A reusable Google Cloud infrastructure foundation designed around modular networking, controlled firewall provisioning, and versioned remote Terraform state.

  • Separated state-bucket bootstrap from the foundation that consumes it.
  • Built reusable network and IAM modules for VPC, subnets, firewall rules, and service accounts.
  • Enabled object versioning on the GCS backend to retain previous state versions.

Terraform · Google Cloud · VPC · GCS · IAM

Object versioning · remote state. A reusable learning foundation, not a full landing zone.

Keyless CI/CD on Google Cloud

A GitHub Actions delivery workflow using Workload Identity Federation to replace static cloud credentials with short-lived access.

  • Automated Terraform planning on pull requests, with a reviewable summary and artifact.
  • Separated manual apply into a fresh planning job and an environment-gated execution job.
  • Authenticated each job through WIF before accessing remote state or Google Cloud APIs.

GitHub Actions · Terraform · WIF · Google Cloud

PR plan is for review; apply uses a fresh plan and an approval gate.

Production-Lite GCP Web Platform

A Google Cloud web platform pattern combining private compute, a managed instance group, health checks, Cloud NAT, and external load balancing.

  • Kept application VMs without external IP addresses, behind an external load balancer.
  • Provisioned a regional managed instance group and an explicit /healthz endpoint.
  • Separated inbound application traffic from outbound access through Cloud NAT.

Terraform · Compute Engine · MIG · Cloud NAT · Load Balancing

Outbound only through Cloud NAT; public entry is handled by the load balancer.

Tools across the work

An application foundation.
An infrastructure focus.

Mobile · Web · Desktop · ERP · IoT · Machine learning

Cloud Infrastructure
Google Cloud · Compute Engine · Cloud Run · VPC · MIG · Cloud NAT · HTTP Load Balancing · Secret Manager · Cloud Monitoring
Platform & DevOps
Terraform · GitHub Actions · GitLab CI/CD · WIF · Docker · Remote State · Drift Detection
Kubernetes & Linux
Kubernetes · kubectl · kubeadm · RBAC · Services · Networking · Storage · Helm · Kustomize · Linux
Software Engineering
Node.js · Express · Prisma · REST APIs · React · PostgreSQL · MySQL · MongoDB · JavaScript

Experience

The work that brought me here.

01 / 04 · Cikarang

Internal applications

Software Engineer Intern

PT Mattel Indonesia · Nov 2022 — Nov 2023

Built internal applications and maintained 11 tools supporting security and facility workflows.

02 / 04 · Jakarta

Software in daily use

VB.NET Developer

Indomaret Group · Nov 2023 — Apr 2024

Maintained VB.NET applications and introduced React with Electron to modernize front-end workflows.

03 / 04 · Jakarta

Business workflows

Oracle NetSuite Technical Consultant

Hand Global Solutions · Apr 2024 — Sep 2025

Turned business requirements into NetSuite customizations and workflow automation.

04 / 04 · Jakarta

Applications, cloud & platform

Application Engineer

PointStar PTE LTD · Sep 2025 — Present

Built applications and cloud infrastructure, then independently built a shared Kubernetes platform for development and staging.

ApplicationsCloudPlatform
Read the full responsibilities
Full career responsibilities
  1. — · Cikarang

    Software Engineer Intern

    PT Mattel Indonesia

    • Built internal ASP.NET MVC applications for security/facility workflows.
    • Maintained and optimized 11 internal applications across ASP.NET, VB.NET, Power Automate, and Power Apps.
  2. — · Jakarta

    VB.NET Developer

    Indomaret Group

    • Built and maintained VB.NET applications backed by MySQL.
    • Delivered software enhancements and production fixes.
    • Introduced React wrapped in Electron.js to modernize front-end workflows.
    • Reduced defects in the RRAK project and improved application stability.
  3. — · Jakarta

    Oracle NetSuite Technical Consultant

    Hand Global Solutions

    • Translated business requirements into technical solutions using SuiteScript and SuiteFlow.
    • Customized NetSuite modules and automated PDF/Excel outputs with XML templates.
    • Supported functional teams through troubleshooting, knowledge transfer, and feature delivery.
  4. — Present · Jakarta

    Application Engineer

    PointStar PTE LTD

    • Independently designed and built the team's on-premises Kubernetes platform for development and staging, covering hardware, networking, GitOps delivery and observability, and onboarded 10 applications for about 11 developers.
    • Designed and deployed Google Cloud infrastructure using VPCs, Managed Instance Groups, Cloud NAT, HTTP Load Balancing, Cloud Run, and Docker.
    • Built keyless CI/CD pipelines with GitHub Actions and Workload Identity Federation, and managed Terraform using modular configurations, remote GCS state, and drift detection.
    • Supported production workloads through monitoring, logging, troubleshooting, performance analysis, and deployment operations.
    • Built backend services and REST APIs for workflow automation, Google Workspace provisioning, and AI-enabled applications.

Certifications

Learning, with something to show for it.

Additional training AWS Academy Cloud Foundations

Engineering notes

I write down the decisions.

  1. Terraform Drift Detection and Recovery on Google Cloud: Plan, Import, State, and GitHub Actions

    Terraform · Google Cloud · State recovery

  2. Terraform CI/CD with Google Cloud: Plan on Pull Request and Apply with Approval

    Terraform · GitHub Actions · Delivery

  3. Terraforming a Production-Lite GCP Web Platform: MIG, Cloud NAT, Load Balancer, and Private Backends

    Google Cloud · Networking · Private compute

  4. Building a GCP Terraform Foundation: VPC, IAM, and Remote State

    Terraform · IAM · Remote state

Read all articles on Dev.to

Beyond the work

A little more about me.

I started in software and enterprise application development. That background shapes how I approach platform work: I care about the developer experience and the infrastructure that supports it.

My focus is on making systems feel seamless and interconnected, while thinking through failure, recovery and cost.

President University

B.Sc. Information Technology · 2020–2023

Magna Cum Laude · GPA 3.95
Scholarship Awardee · Thesis Grade A

Bangkit Academy

Mobile Development Cohort · 2022
Distinction — 98.5
Top 15 / 433 capstone teams

Languages

Indonesian
Native
English
Professional Working Proficiency