Deployment

Step-by-step guide for deploying web, backend, and mobile updates. For developers and engineers releasing changes.

Operations Reference

This page covers the developer workflow. For checklists, rollback steps, and the deploy order rule, see Operations: Deployment Guide →.

---

Three Deployment Targets

Target	How	Trigger
Web (Vite React SPA)	Automatic via CI	Merge to main (via PR)
Backend (NestJS + Fastify)	Automatic via CI	Merge to main (via PR)
Mobile (Flutter → App Stores)	Manual + review	Developer builds + uploads

The CI pipeline builds Docker images for both frontend and backend, pushes them to DigitalOcean Container Registry (DOCR), and signals Dokploy on the VPS to pull and redeploy. Dokploy does not build — it only pulls pre-built images.

Branch → environment mapping:

Branch	Environment
develop	Staging
main	Production

---

Web Deployment (CI-driven)

The web SPA deploys automatically when CI runs on main. Developers don't push to main directly. Branch off main, then open two PRs from the same branch: first into develop for staging validation, then into main for production. Never open a PR from develop into main, and never branch off develop:

# 1. Branch off main, do the work, then open a PR from that branch into develop
# 2. Once validated on develop/staging, open a SECOND PR from the SAME branch into main
#    (never open a PR from develop into main)
# 3. On merge to main, CI:
#    → builds the Vite React SPA Docker image
#    → pushes image to DOCR
#    → notifies Dokploy, which pulls and restarts the nginx container
#    → serves the SPA from the VPS

To verify after deploy, hit the production URL and confirm the page loads. There is no Vercel preview URL for the main marketplace; use the staging deploy on develop as the preview environment.

---

Backend Deployment (CI-driven)

The NestJS backend deploys the same way as the web frontend — CI builds the Docker image and Dokploy pulls it:

# 1. Open a PR (feature/* → develop, then same branch → main)
# 2. On merge to main, CI:
#    → builds the NestJS backend Docker image
#    → pushes image to DOCR
#    → notifies Dokploy, which pulls and restarts the backend container

# Verify health after deploy (replace with actual production hostname)
curl https://api.pasarseken.id/health
# Expected: { "ok": true, "version": "..." }

Database migrations are applied automatically as part of the backend startup sequence. Ensure migrations are tested against staging (develop) before merging to main.

---

Mobile Deployment

iOS

cd mobile

# 1. Bump version in pubspec.yaml
# 2. Build release
flutter build ios --release

# 3. Open in Xcode
open ios/Runner.xcworkspace

# 4. Archive → Upload to App Store Connect
# 5. Submit for TestFlight review
# 6. Distribute via TestFlight → then Submit for App Store Review

Android

cd mobile

# 1. Bump version in pubspec.yaml
# 2. Build release bundle
flutter build appbundle --release

# 3. Open Google Play Console
# 4. Upload .aab to Internal Testing
# 5. Promote to Closed Testing → Production

Mobile Release Lead Time

App Store review: 1-7 days. Plan mobile releases accordingly. Business rule changes (fees, deadlines) in app_config.dart are blocked behind this timeline.

---

Pre-Deployment Checklist

Run pnpm preflight first, it must pass:

• pnpm preflight passes (typecheck + lint + tests)
• No console.log left in production code
• No hardcoded API keys or secrets
• No hardcoded colors (use theme tokens, see Brand Guidelines →)
• Error states handled with user-friendly messages
• Loading states shown during async operations
• Mobile responsive design verified
• Bahasa Indonesia text reviewed
• New API endpoints have rate limiting
• New API endpoints have input validation (Zod / class-validator)
• Any new DB migration has a .down.sql rollback and was applied clean on staging

---

Deploy Order Rule

Order Matters

• Adding new endpoints: Deploy backend first, then frontend
• Removing old endpoints: Deploy frontend first, then backend
• Both changed: Backend → verify health → then frontend

Both deploy through CI on the same branch merge, so coordinate timing by verifying the health endpoint before traffic shifts to the new frontend.

---

Post-Deployment Checks

• Production site loads correctly
• API health endpoint returns 200
• Critical user flow works: browse → view → buy → pay → ship → confirm
• No new errors in backend logs (check Dokploy log stream)
• Payment webhooks still processing (check Xendit dashboard)

---

Rollback

Platform	Rollback Method
Web	Redeploy the previous DOCR image tag via Dokploy, or git revert the merge commit and push to main to trigger CI
Backend	Same as web — redeploy previous image or revert and push
Mobile	Cannot rollback; prepare and expedite a hotfix build

For incident-level rollbacks and recovery steps, see Maintenance Guide →.

---

Environment Promotion

Local → Staging (develop branch) → Production (main branch)

Never deploy directly to production without testing on staging first. For backend changes, test against a local database before pushing to develop.

See Local Setup → for running the local stack.

---

This Docs Site

docs.pasarseken.id (SEKENDocs, this site) is a separate Docusaurus project and still deploys via Vercel, independent of the marketplace's move to Dokploy.