Configure and verify an OCI release

Configure and verify an OCI release

Prerequisites

Install the CLI and approved deployment packages. Use oci-adb or its alias oci-adb-standard. The host owns actual Oracle/identity credentials, an environment-wide lock, all-instance drain, immutable images and reviewed migration executors. Examples use reserved documentation domains and synthetic identifiers.

Public import

Install the package; the subpath below is an import target, not a separate package. Registry installation requires a published EAOS release; before publication use the owning workspace’s checksum-verified build artifact.

bun add @alneas/eaos-cli

import { definePlatformOperations } from '@alneas/eaos-cli/platform/operations'

export const defineHostOperations = definePlatformOperations

Bun/server tooling only. OCI generation requires the Pulumi/OCI peers declared by the CLI. Defining host operations does not execute a release; credentials and live executors remain host-owned.

Step-by-Step Implementation

Declare package selection in eaos.platform.json:

{
  "preset": "oci-adb",
  "platform": { "appName": "example-platform", "baseDomain": "example.com" },
  "plugins": ["@example/standard-bundle"],
  "corporatePackages": [
    { "id": "example-extension", "path": "./vendor/example-extension", "tenants": ["example-tenant"] }
  ]
}

Each installed package exports ./deployment.json with asset SHA-256, runtime, lifecycle bundle, components and tasks. Inspection does not execute the runtime factory. loadRegisteredPlatformModules receives host-verified tenant IDs and bindings. stagePlatformPackages copies verified assets into staging; ship that entire tree and its fixed runtime dependencies.

Frontend and API/MCP components use their declared roles. Jobs/workflows use a configured Worker image; database components use the Oracle target. Required additional databases, existing resources, Functions, native capabilities or external services need explicit placements. Unresolved required components fail generation. Selecting code never grants tenant access.

Generate infrastructure definitions

eaos preset:init
cd pulumi
bun install
pulumi stack init staging
pulumi preview

Set the actual compartment, availability domain, supported images, SSH CIDR/key, database version and storage namespace through the generated Pulumi schema. Supply database passwords as Pulumi secrets. Initialization writes source and preserves edits; preview does not apply resources.

The template describes an edge host, private ARM worker, NAT/service gateways, network ACLs, protected ADB, private versioned Object Storage and Vault. The host supplies IAM, DNS/TLS and explicit existing-resource adoption. pulumi/custom.ts can customize arguments or add resources. Keep secret outputs out of platform JSON and receipts.

Bind reviewed host operations

Implement PlatformOperations in trusted eaos.operations.ts using definePlatformOperations from @alneas/eaos-cli/platform/operations. The host provides environment locking, lifecycle catalog/executors, health endpoints and bootstrap identity/control-DB/admin-code adapters. Real adapters must not be replaced by empty success callbacks. Store only hashes for short-lived single-use administrator codes and deliver the plaintext directly to the operator.

Configure immutable deployment images and existing Kamal/SSH bindings. Release rejects dev, local and latest tags. Host hooks may supply deploy({ role, image, version, configFile, context }) and bootstrap.provisionInfrastructure(context, stack) to retain existing Kamal/Pulumi identities. Target versions and stack are checked before execution.

Inspect the plan before requesting a real operation:

eaos platform:generate
eaos bootstrap --stack org/example-platform/staging --plan
eaos release --plan
eaos up --plan

--plan does not import host operation code. Actual execution obtains both local and shared environment locks, verifies package/config/source/lockfile hashes, then performs the selected operation. Bootstrap applies infrastructure, initializes the control DB and identity, and delivers a one-use registration code. Release installs/updates selected lifecycle releases, requires drain for active upgrades, deploys Worker → Backend → Frontend and checks readiness plus X-EAOS-Release against each image version. It restores only activations that the operation itself suspended, then appends a receipt. New tenants are never enabled automatically.

Supply a baseline or local Compose runtime

Pass reviewed baselines: [{ backendId, baseline }] with the matching target Data Contract. Existing ledgers require exact applied-history checksums and rebase without DDL; new databases apply target DDL normally. Preserve the source archive and old ledger. See baseline generation for disposable local Oracle/PostgreSQL/SQLite compilation; it does not inspect production databases.

For eaos up, the host supplies local origins, image builds and the runtime identity configuration/password-file contract. TLS directories are required when HTTPS is selected. The CLI does not replace existing passwords or volumes. Startup follows DB → identity migration → application, and readiness failures remain failures.

Verification

Inspect generated inventory, runtime contract, placement plans and immutable image versions. Bind actual adapters under src/ or scripts/; those, Pulumi sources and operation declarations participate in the release input hash. Every external adapter rechecks real state immediately before execution. Confirm role-specific readiness and version headers before accepting a deployed release.

Troubleshooting / Common Pitfalls

• A required placement must resolve before generation; optional native features remain visibly unadopted.
• A failed step stops later steps and appends failure evidence. Reconcile dirty DDL and actual ledger state before retrying.
• Locks do not expire automatically. Inspect the owner and maintenance state before recovery.
• Resume suspended plugins with an explicit lifecycle operation after recovery.
• Private storage flags are not proof of actual provider protection. Check the host’s real configuration.

See the provider specifications for ADB network ACLs and Object Storage privacy/versioning.