eNerds × Invarosoft · software delivery proposal

eNerds × Invarosoft

A software delivery system we can trust, explain, and recover

An isolated eNerds development and release capability—built on proven platform foundations, governed in phases.

Safer releasesRecoverable servicesAuditable evidence

Management proposal · implementation not yet started

INTERNAL DISCUSSION01

eNerds × Invarosoft · software delivery proposal

eNerds × Invarosoft

A software delivery system we can trust, explain, and recover

An isolated eNerds development and release capability—built on proven platform foundations, governed in phases.

Safer releasesRecoverable servicesAuditable evidence

Management proposal · implementation not yet started

INTERNAL DISCUSSION01

×INVAROSOFT

The decision

The decision today

Approve the direction—and authorize a controlled first phase

We are asking for program endorsement plus read-only discovery, not a blank cheque or an immediate production cutover.

Endorse

A separate eNerds delivery cell using the shared platform—not an Invarosoft tenant, product fork, or new cloud island.

Discover

Authorize source, AWS, database, DNS, backup, and deployment discovery so the executable plan is based on evidence.

Gate

Return for explicit approval before external mutations, migration, public exposure, or any production connector is activated.

The immediate output is a costed, sequenced implementation backlog with risks, owners, and acceptance checks.

INTERNAL DISCUSSION02

×INVAROSOFT

Business case

Why change the operating model

Software risk lives in the hand-offs

Source control, builds, environments, approvals, deployment, and backups can each work individually while the overall release remains fragile.

SourceWhat changed?

BuildWhat was produced?

ApproveWho accepted risk?

DeployWhat is running?

RecoverCan we restore it?

!Manual knowledge becomes a key-person dependency

!A green server can hide an unqualified release

!Rebuilding for each environment changes the thing being approved

!A backup without a restore rehearsal is only a hope

INTERNAL DISCUSSION03

×INVAROSOFT

Target state

What we are proposing

A small, isolated eNerds delivery cell

eNerds owns its identities, repositories, credentials, applications, releases, and audit trail. Invarosoft supplies the reusable platform fabric.

People & access

eNerds SSO

MFA + roles

WireGuard + bastion

Build & evidence

eNerds GitLab

Isolated runners

Immutable artifacts

Managed staging

Windows IIS / ncapi

Linux PHP / NerdCentral

MySQL-compatible DB

Recovery & oversight

Encrypted backups

Monitoring + audit

Restore rehearsals

INTERNAL DISCUSSION04

×INVAROSOFT

Delivery

The release flow

Build once. Promote the same artifact with proof.

Every environment receives the same versioned content. Configuration changes by environment; the approved software does not.

Commit

Protected source ref

author + SHA

Build

Isolated runner

logs + toolchain

Qualify

Tests + scans

SBOM + findings

Artifact

Immutable package

hash + provenance

Promote

Dev → stage → prod

approval + result

Integrity ruleA rebuild is a new release subject. It cannot inherit another artifact’s approval.

INTERNAL DISCUSSION05

×INVAROSOFT

Delivery

What proper CI/CD changes

Automation makes the safe path the easy path

CI/CD is not “deploy every commit to production.” It is a controlled conveyor belt with evidence and gates.

Without the system

Build steps live in personal knowledge

Environment differences surface late

Approval is separated from artifact identity

Rollback depends on reconstructing the prior state

With the system

Builds are deterministic and attributable

Stage exercises the exact production candidate

Approval is bound to evidence and artifact hash

The previous version and recovery path are recorded

Fasterroutine change

Saferhigh-risk change

Cleareraudit & ownership

INTERNAL DISCUSSION06

×INVAROSOFT

Assurance

Release assurance

Three separate questions—three separate answers

A healthy process is not proof that the release was tested, approved, or safe to promote.

Deployment health

Is the deployed service responding correctly?

Process, application, database-safe, and dependency probes

Release qualification

Did this exact artifact meet the required policy?

Tests, scans, SBOM, schema contract, freshness, and evidence hashes

Promotion authorization

Who accepted any remaining risk?

Attributable approval, exception, expiry, and segregation of duties

Assurance can block promotion. It must never block rollback, repair, restore, or recovery.

INTERNAL DISCUSSION07

×INVAROSOFT

Recovery

How backups will work

Layered recovery, with restoration as the proof

No single disk, host, site, or backup format is allowed to be the only recovery path.

Application-aware

GitLab, databases, configuration, secrets, keys, and persistent content captured in the format each service can restore.

Fast VM recovery

Encrypted guest volumes plus incremental, deduplicated VM backups for efficient local recovery.

Independent archive

Daily paired archives on separate SG1/SG2 storage, with controlled daily and monthly retention.

Off-site disaster recovery

Encrypted secondary copies in a narrowed, prefix-scoped S3 target—without broad cloud keys on archive hosts.

Enrollmonitorsamplerestoretimedocumentrepeat

INTERNAL DISCUSSION08

×INVAROSOFT

Recovery

Existing platform evidence

The recovery machinery is real; eNerds enrollment is the next control

Invarosoft already operates monitored archive and deduplicated backup paths. eNerds services will not be called protected until they are individually enrolled and restore-tested.

161current protected sources

0stale or missing sources

2 / 2archive hosts available

308archive copies at checkpoint

Recurring SG3/SG4/SG5 workstation backups completed

Incremental runs reused 96–98% in sampled deltas

Temporary-VM restores proved scheduled backup media

Archive extraction and database-dump integrity rehearsed

Capability evidence ≠ eNerds coverage. Each new service needs encryption, backup ownership, alerting, retention, and a timed restore rehearsal.

INTERNAL DISCUSSION09

×INVAROSOFT

Security

Security and organizational boundary

Shared platform does not mean shared authority

eNerds remains a separate security and administrative boundary, even though it reuses the same platform release stream and physical capacity.

eNerds-owned

SSO registration and user roles

GitLab, runners, and branch policy

Application and deployment credentials

Artifacts, approvals, and audit evidence

DNS/certificate and backup ownership

Platform-scoped

Physical host capacity and placement

Network and VM provisioning fabric

Infrastructure monitoring and backup transport

Narrow named inter-manager operations

Common platform updates—without a fork

Narrow service contract

No copied Invarosoft identities, runners, AWS keys, signing keys, or broad manager bearer tokens.

INTERNAL DISCUSSION10

×INVAROSOFT

Scope

Right-sized first scope

Start with recoverable staging—earn the right to touch production

The initial program creates the operating system for delivery. Production integration follows only after the staging path and recovery controls are proven.

Initial program

Recoverable managed staging

eNerds manager, SSO, roles, network boundary

GitLab migration from Gitea

Isolated Linux and Windows runners

Windows IIS / ncapi staging

Linux PHP / NerdCentral staging

MySQL-compatible staging database

Backups, monitoring, audit, and restore drills

Later · separate gates

Production and data extensions

Narrow AWS Elastic Beanstalk production connector

Application-specific ncapi production deployment

Separately approved canary and rollback windows

Sanitized, contract-driven support-data synchronization

Any first-class multi-company platform capability

INTERNAL DISCUSSION11

×INVAROSOFT

Plan

Phased delivery

Every phase ends in evidence, not optimism

Management can stop, reshape, or authorize the next phase at each decision gate.

Discover

Inventory source, AWS, data, DNS, RPO/RTO, roles

Costed executable backlog

1–2

Isolate

Identity defaults, manager boundary, network, access, recovery

Boundary + restore proof

3–4

Deliver staging

GitLab, runners, database, ncapi, NerdCentral

Repeatable release + rollback

Activate assurance

Policy, evidence, approvals, failed-gate exercises

Management-approved controls

6–7

Extend carefully

Production connectors, then sanitized data sync

Separate change windows

INTERNAL DISCUSSION12

×INVAROSOFT

Value

How management will know it is working

Measure flow, safety, recovery, and governance

Phase 0 establishes baselines. Management then approves targets that reflect business impact and the eNerds control system.

Lead time

Approved change → running stage release

Change failure rate

Deployments needing rollback or repair

Recovery time

Timed service restore and release rollback

Evidence coverage

Releases with complete tests, scans, SBOM, approvals

Control exceptions

Count, owner, expiry, and compensating action

Backup confidence

Current sources, failures, restore samples, achieved RPO

INTERNAL DISCUSSION13

×INVAROSOFT

Value

Reuse before expansion

Use existing capacity—allocate from evidence

The current SG3/SG4/SG5 checkpoint shows enough aggregate headroom for the proposed first cell, without preallocating two oversized resource groups.

31–41 GiBestimated always-on memory

43–53 GiBestimated peak with both runners active

On demandrunner capacity when jobs execute

Place persistent services across failure domains after fresh pressure checks

Scale database and GitLab from observed workload—not assumptions

Prefer simple recoverable services over premature HA

Do not mistake local free space for a recovery strategy

Phase 0 validates workload sizing and identifies any external license, storage, or cloud costs before provisioning.

INTERNAL DISCUSSION14

×INVAROSOFT

Decision

Approval requested

Authorize the program direction and Phase 0

Give the team permission to replace unknowns with evidence and return with a sequenced implementation decision.

Endorse the architecture

Separate eNerds boundary, shared platform fabric, no long-lived fork.

Authorize read-only discovery

Gitea, AWS, Aurora, DNS, certificates, backups, and deployment topology.

Nominate control owners

SSO, DNS, AWS, data, release approval, backup RPO/RTO, and ISMS mapping.

Agree the next gate

Review cost, sequence, risks, and acceptance checks before any external mutation.

Not authorized by this approval: production deployment, public-IP binding, DNS change, credential copying, data movement, or Gitea retirement.

INTERNAL DISCUSSION15

The outcome

Move fast when it is routine. Slow down when risk demands it. Recover every time.

A delivery capability that gives developers momentum, management visibility, customers protection, and auditors attributable evidence.

One artifactExplicit gatesTested recovery

Approve a system—not a collection of scripts, servers, and good intentions.

×INVAROSOFT

INTERNAL DISCUSSION16

×INVAROSOFT

Appendix

Indicative initial resource envelope

Provisioning targets will be refreshed after discovery and before any allocation.

Component

vCPU

RAM

Operating note

eNerds manager

4 GiB

Separate identity, DB, and credentials

GitLab

8 GiB

Encrypted persistent volume; scale from evidence

Staging database

2–4

8–16 GiB

Final size follows Aurora discovery

Linux PHP staging

2–4 GiB

Stateless release content where practical

Windows IIS / ncapi

4 GiB

Tasks modeled as guarded singletons

Bastion + WireGuard

4.5–5 GiB

Separate access and gateway lifecycle

Linux runner

4 GiB

On demand; isolated

Windows runner

8 GiB

On demand; isolated

INTERNAL DISCUSSION17

×INVAROSOFT

Appendix

Evidence retained for each releasable artifact

The system supports the eNerds information-security control environment; it is not certification by itself.

Identity

Repository + protected ref

Commit + author

Pipeline/job/runner

Approver identities

Integrity

Artifact checksum

Dependency lock

Tool versions

Signature/provenance when adopted

Quality & security

Test results

Secret/SAST/SCA results

SBOM

Schema contract + exceptions

Operation

Environment + configuration revision

Deployment result

Health evidence

Exact rollback identity

INTERNAL DISCUSSION18

×INVAROSOFT

Appendix

Non-negotiable guardrails

These constraints protect recovery, privacy, and accountability while the capability grows.

Missing, stale, timed-out, crashed, or malformed assurance evidence is never green.

Recovery actions remain available even when promotion is blocked.

Runners do not hold standing staging or production deployment credentials.

Legacy-backed schema changes remain additive, idempotent, and backward compatible.

No intrusive production DAST and no production client database clone into staging.

External mutations and production connectors require separate explicit windows.

INTERNAL DISCUSSION19