Midnight Blockchain Development - Advanced › 1. Production architecture and compatibility management › Production architecture and compatibility management
Learning viewShow only the learning panels you need.

No video assigned to this section

The lesson can still contain reading, examples, practical work and a quiz.

Production architecture and compatibility management

1. Production architecture and compatibility management · 0 min · Midnight / Compact

Course path: Midnight Blockchain Development - Advanced. This chapter is part of a progressive Beginner to Intermediate to Advanced Midnight developer pathway.

Production architecture and compatibility management

Advanced Midnight engineering starts with reproducible, compatible component sets across development, staging, and production-like environments.

Learning objectives

  • Read the compatibility matrix as a deployment contract.
  • Pin environment-specific component versions.
  • Detect version drift automatically.
  • Plan upgrades and rollback points.

Core lesson

Midnight DApps depend on a coordinated set of runtime, compiler, SDK, indexer, proof, and node components. The official release overview explicitly tells developers to use compatible component versions together.

A repository example can lag behind the current tested release. For example, the node-docker proof-server compose file inspected during this course build pins an older image than the current official compatibility matrix. This is precisely why production automation must not treat example tags as authoritative.

A deployment manifest should record the network, node version, indexer version, proof-server version, Compact compiler, Midnight.js version, and the exact contract build commit. This makes incidents reproducible.

Upgrade plans should define compatibility tests, data backup, migration steps, canary checks, and rollback criteria before a version is changed.

Recommended workflow

  1. Read the current matrix.
  2. Create a version-lock file.
  3. Compare it with repository image tags.
  4. Fail CI when unexpected drift is detected.
  5. Document rollback steps.

Engineering and security note

Version drift is a security and availability risk. Treat compatibility checks as part of CI/CD.

Hands-on goal

Create a machine-readable compatibility manifest for Preview, Preprod, and Mainnet deployments.

Open-source references

Compatibility note: The version numbers in this package are a research snapshot from 2026-09-09. Before running commands, compare them with the current Midnight compatibility matrix and release notes.

Practical tasksLocal progress: 0%

MBA1T1 - Practical Task 1

Record current component versions.

MBA1T2 - Practical Task 2

Flag any mismatch with docker-compose files.

MBA1T3 - Practical Task 3

Add a CI check for version drift.

MBA1T4 - Practical Task 4

Write one rollback criterion for node, indexer, and DApp upgrades.

Lab note: This is a snapshot, not a permanent pin. Regenerate it from the current compatibility matrix during upgrades.
Next →
Code LabReady
Code output will appear here.
Practice Lab - Production architecture and compatibility management: Use this editable lab to practise the configuration or code from the lesson. This is a snapshot, not a permanent pin. Regenerate it from the current compatibility matrix during upgrades.