CodeHero PROΕλληνικάBook a presentation

CodeHero · Your own software factory

For developers · architecture and mechanisms

The whole factory.
Explained.

A software factory for the person who knows the business, rather than a coding assistant. Here are the system boundaries, responsibilities and failure paths.

CodeHero asks, builds, checks, runs and maintains on your server. You decide the rules; you don’t write code.

Read the system overview
You decide
CodeHeroBuilds · checks · maintainsThe knowledge stays inside
On your server

For engineers and developers

How the factory works, from the inside.

People decide what the software must do; CodeHero does the rest. It plans the work, has AI builders write it, has a different AI check it, fixes what fails, runs the result and keeps every decision on record. Below, each part in plain words first — the technical detail is one click away.

  1. Human: intent + decisions
  2. Factory: execution + checking
  3. Platform: running app + knowledge

Execution is coordinated

The panel records work. The scheduler selects eligible tickets. Agents use tools within the project’s environment. Dependencies, role restrictions and review gates determine what can start and what can finish.

Verification has its own role

The normal verifier does not edit product code. Findings become scoped repairs, followed by a recheck. Eligibility restrictions and a circuit breaker prevent an unbounded claim of autonomous success.

State outlives the model

Specifications, tickets, conversations and the knowledge graph belong to the project. A provider change can reuse that state; it does not imply identical model capability or perfect recall.

01 · What runs on your server

Everything runs on your server.

The control panel, the scheduler that hands out the work, the tools, and every project’s files and data live on your own server. Only the requests to the AI services leave it — and you choose which services.

Where the work lives

Where the work livesThe installation holds the panel, project files, database and work record. Selected context goes through configured model connections. Cloud calls leave the installation. Declared protected values are filtered within the documented limits.Your installationPanel + work historyProject + databaseContext boundaryConfigured AILocal or cloudWhere the work livesThe installation holds the panel, project files, database and work record. Selected context goes through configured model connections. Cloud calls leave the installation. Declared protected values are filtered within the documented limits.Your installationPanel + work historyProject + databaseContextConfigured AILocal or cloud
Self-host the factory. Choose the model connections.
Read the diagram as text
  1. The installation holds the panel, project files, database and work record.
  2. Selected context goes through configured model connections. Cloud calls leave the installation.
  3. Declared protected values are filtered within the documented limits.

Inside one installation

Inside one installationThe Flask and Socket.IO panel presents projects and tickets. The daemon schedules eligible work and stores conversation and ticket state in the database. An agent uses its provider-family adapter through an API or CLI runtime. Selected context goes to the configured cloud or local model. Self-hosting does not mean that cloud model calls stay on the server. Agents use MCP tools; hooks enforce applicable runtime checks. Tools operate on project files and services, including container environments. nginx routes project previews. The database retains the work record.Flask + Socket.IOWeb panelclaude-daemon.pySchedulerProvider adaptersAPI / CLIPlatform databasetickets · historymcp_server.pyTools + runtime hooksConfigured modelslocal or cloudContainersfiles · servicesnginx / previewInside one installationThe Flask and Socket.IO panel presents projects and tickets. The daemon schedules eligible work and stores conversation and ticket state in the database. An agent uses its provider-family adapter through an API or CLI runtime. Selected context goes to the configured cloud or local model. Self-hosting does not mean that cloud model calls stay on the server. Agents use MCP tools; hooks enforce applicable runtime checks. Tools operate on project files and services, including container environments. nginx routes project previews. The database retains the work record.01Flask + Socket.IOWeb panel02claude-daemon.pyScheduler03Provider adaptersAPI / CLI04Platform databasetickets · history05mcp_server.pyTools + runtime hooks06Configured modelslocal or cloud07Containersfiles · services08nginx / preview
The panel, scheduler, tools and project state run on the installation. Model calls cross a configured connection.
Read the diagram as text
  1. The Flask and Socket.IO panel presents projects and tickets. The daemon schedules eligible work and stores conversation and ticket state in the database.
  2. An agent uses its provider-family adapter through an API or CLI runtime. Selected context goes to the configured cloud or local model. Self-hosting does not mean that cloud model calls stay on the server.
  3. Agents use MCP tools; hooks enforce applicable runtime checks. Tools operate on project files and services, including container environments. nginx routes project previews. The database retains the work record.
Implementation notes and boundaries

The Flask and Socket.IO panel presents projects and tickets. The daemon schedules eligible work and stores conversation and ticket state in the database.

An agent uses its provider-family adapter through an API or CLI runtime. Selected context goes to the configured cloud or local model. Self-hosting does not mean that cloud model calls stay on the server.

Agents use MCP tools; hooks enforce applicable runtime checks. Tools operate on project files and services, including container environments. nginx routes project previews. The database retains the work record.

02 · Work in order

Work happens in order, step by step.

Every piece of work is a ticket. A ticket starts only when the tickets it depends on are finished, so nothing is built on top of something unfinished. When you need to, you can still start one at once.

A graph of work, with explicit gates

A graph of work, with explicit gatesLower sequences must be done or skipped before higher sequences run. Equal sequence numbers can run in parallel within the available slots when file ownership permits it. Explicit dependencies require done or skipped in both modes. A parent is an implicit dependency, with defined exceptions for children of parked tickets. Relaxed flow allows the reviewer to close a qualifying completed report. Strict flow leaves closure to a person. A request for human input keeps work open; the closure reviewer is separate from the verification ticket. Forced tickets can bypass sequence, dependencies, parent and the normal slot count, using an extra slot. The upgrade gate and retry cooldown still apply.Plan · sequence 1Build A · sequence 2Build B · sequence 2Verify · sequence 3Reviewer / humancloses the ticketForced startextra slotA graph of work, with explicit gatesLower sequences must be done or skipped before higher sequences run. Equal sequence numbers can run in parallel within the available slots when file ownership permits it. Explicit dependencies require done or skipped in both modes. A parent is an implicit dependency, with defined exceptions for children of parked tickets. Relaxed flow allows the reviewer to close a qualifying completed report. Strict flow leaves closure to a person. A request for human input keeps work open; the closure reviewer is separate from the verification ticket. Forced tickets can bypass sequence, dependencies, parent and the normal slot count, using an extra slot. The upgrade gate and retry cooldown still apply.01Plan · sequence 102Build A · sequence 203Build B · sequence 204Verify · sequence 305Reviewer / humancloses the ticket06Forced startextra slot
Sequence, dependencies and parent links constrain ordinary scheduling. Forced start is an explicit exception.
Read the diagram as text
  1. Lower sequences must be done or skipped before higher sequences run. Equal sequence numbers can run in parallel within the available slots when file ownership permits it.
  2. Explicit dependencies require done or skipped in both modes. A parent is an implicit dependency, with defined exceptions for children of parked tickets.
  3. Relaxed flow allows the reviewer to close a qualifying completed report. Strict flow leaves closure to a person. A request for human input keeps work open; the closure reviewer is separate from the verification ticket.
  4. Forced tickets can bypass sequence, dependencies, parent and the normal slot count, using an extra slot. The upgrade gate and retry cooldown still apply.
Scheduling rules and exceptions

Lower sequences must be done or skipped before higher sequences run. Equal sequence numbers can run in parallel within the available slots when file ownership permits it.

Explicit dependencies require done or skipped in both modes. A parent is an implicit dependency, with defined exceptions for children of parked tickets.

Relaxed flow allows the reviewer to close a qualifying completed report. Strict flow leaves closure to a person. A request for human input keeps work open; the closure reviewer is separate from the verification ticket.

Forced tickets can bypass sequence, dependencies, parent and the normal slot count, using an extra slot. The upgrade gate and retry cooldown still apply.

03 · Checking and fixing

The one who finds the problem checks the fix.

When the checker finds a problem, the builder gets a precise repair job. The same checker then tests it again. If the same problem keeps coming back, the factory stops and asks a person, instead of trying forever.

What the company asked for

“Staff request equipment through the app. Up to €500 it is approved automatically. Above €500 a manager approves it — but never their own request.”

  1. Build

    Junior model · GPT Codex

    Done

    Built the application and tried every rule in the browser.

    • Requests up to the approval limit are approved automatically; above it they wait for a manager
    • A manager cannot approve a request they submitted
    • Completed requests cannot be deleted

    114 actions

  2. Independent check

    Senior model · from a different AI company (Claude)

    2 problems found

    Every business rule passed. Two layout problems on phones.

    • All five agreed checks: passed
    • Long text was cut off in the phone view
    • Two controls in the top bar had different heights

    Opened a repair · changed no product code

  3. Repair

    Junior model · GPT Codex

    Fixed

    Fixed both layout problems and told the checker.

    • Long text now wraps on phones — no sideways scrolling
    • The top-bar controls now have the same height

    58 actions

  4. Recheck

    The same independent checker

    Passed

    Checked the repair and everything again.

    • Verdict: pass — it took 2 rounds
    • The agreed checks and extra tricky cases: all passed
    • Its own test entries removed afterwards

    103 actions in all

The recorded repair loop

The recorded repair loopA junior model builds the equipment-request app. A senior model from another family verifies it and finds two layout problems. The builder family fixes the phone cards and header control heights. The verifier rechecks and records a pass in round two.Build114 tool callsVerify103 tool callsFix58 tool callsRecheckPass · 2 roundsThe recorded repair loopA junior model builds the equipment-request app. A senior model from another family verifies it and finds two layout problems. The builder family fixes the phone cards and header control heights. The verifier rechecks and records a pass in round two.Build114 callsVerify103 callsFix58 callsRecheckPass
15 October 2026 · two verification rounds · one repair ticket.
Read the diagram as text
  1. A junior model builds the equipment-request app.
  2. A senior model from another family verifies it and finds two layout problems.
  3. The builder family fixes the phone cards and header control heights.
  4. The verifier rechecks and records a pass in round two.
How it works underneath

One verifier owns the repair episode

One verifier owns the repair episodeA plan defines acceptance. The builder implements it. A verifier checks the requirements and its own negative cases; the normal verifier does not edit application code. Findings produce fix tickets. The verifier parks, receives their replies, and rechecks the findings and affected acceptance items. The cycle belongs to the parent part, not to a new ticket name. The circuit breaker stops after three failed repair cycles for the same part, two consecutive failed repairs of the same acceptance item, or two disputes on the same finding. The initial finding is not a failed repair. The human may authorize another cycle, change the criterion, park the part, or authorize direct repair with a different-family peer check. That last option is the explicit exception to the verifier’s no-edit rule.PlanningBuilder familyOther-family verifierAgreed planAcceptance itemsBuildProduct changesVerifyNo product editsScoped fixReply to verifierRecheckSame verifierUnresolved finding → next cycleCircuit breakerHuman decisionPass + evidenceOne verifier owns the repair episodeA plan defines acceptance. The builder implements it. A verifier checks the requirements and its own negative cases; the normal verifier does not edit application code. Findings produce fix tickets. The verifier parks, receives their replies, and rechecks the findings and affected acceptance items. The cycle belongs to the parent part, not to a new ticket name. The circuit breaker stops after three failed repair cycles for the same part, two consecutive failed repairs of the same acceptance item, or two disputes on the same finding. The initial finding is not a failed repair. The human may authorize another cycle, change the criterion, park the part, or authorize direct repair with a different-family peer check. That last option is the explicit exception to the verifier’s no-edit rule.Plan → acceptanceBuild → implementationVerify → findingsFix → replyRecheck → pass or repeatAt the limit → human
A failed check creates scoped repairs. The same verifier rechecks; repeated failure reaches a human decision.
Read the diagram as text
  1. A plan defines acceptance. The builder implements it. A verifier checks the requirements and its own negative cases; the normal verifier does not edit application code.
  2. Findings produce fix tickets. The verifier parks, receives their replies, and rechecks the findings and affected acceptance items. The cycle belongs to the parent part, not to a new ticket name.
  3. The circuit breaker stops after three failed repair cycles for the same part, two consecutive failed repairs of the same acceptance item, or two disputes on the same finding. The initial finding is not a failed repair.
  4. The human may authorize another cycle, change the criterion, park the part, or authorize direct repair with a different-family peer check. That last option is the explicit exception to the verifier’s no-edit rule.
CIRCUIT BREAKER
3

failed repair cycles

2

consecutive failed repairs
of the same acceptance item

2

disputes
on the same finding

Any one threshold pauses the episode for a human decision. The initial finding is not a failed repair. The direct-repair exception requires explicit authorization and a different-family peer check.

04 · Choosing the AI

The right AI for each job.

Simple jobs go to fast, low-cost AI models; demanding ones to stronger models; the checks to a model from a different company. A table of every available model helps choose — its scores are estimates until each model has been measured.

Recorded build

GPT Codex

Junior · 114 tool calls

Independent verification

Claude

Senior · 103 tool calls

The repair returned to the builder’s family: 58 tool calls. These counts describe the recorded run; they are not a cost or speed benchmark.

How it works underneath

Choose a model for the work

Choose a model for the workActive providers expose models, role defaults, vision support, cost and score provenance. Master, senior and junior are role assignments. A ticket may select a concrete model; otherwise it uses the role default. Blended list cost weights input to output at 3:1. Subscription effective cost uses a default ×0.1 factor for routing. It is a policy weight, not an invoice or a savings claim. score_source distinguishes rated, estimated and unknown. Ledger projects impose provider-and-role eligibility: validated, verify or excluded. Restricted work needs an eligible validated verifier from another family; the platform reroutes or holds when that condition cannot be met. Outside mandatory restrictions, a single-family verification must be labeled as such. A second run from the same family is not represented as an independent family opinion.Task + roleActive model tablecapability · costLedger eligibilityTicket modelor role defaultOther-family verifywhen requiredNo eligible verifierask the humanChoose a model for the workActive providers expose models, role defaults, vision support, cost and score provenance. Master, senior and junior are role assignments. A ticket may select a concrete model; otherwise it uses the role default. Blended list cost weights input to output at 3:1. Subscription effective cost uses a default ×0.1 factor for routing. It is a policy weight, not an invoice or a savings claim. score_source distinguishes rated, estimated and unknown. Ledger projects impose provider-and-role eligibility: validated, verify or excluded. Restricted work needs an eligible validated verifier from another family; the platform reroutes or holds when that condition cannot be met. Outside mandatory restrictions, a single-family verification must be labeled as such. A second run from the same family is not represented as an independent family opinion.01Task + role02Active model tablecapability · cost03Ledger eligibility04Ticket modelor role default05Other-family verifywhen required06No eligible verifierask the human
The model table is a selection aid. Estimated scores and subscription weighting are not measured performance or billing discounts.
Read the diagram as text
  1. Active providers expose models, role defaults, vision support, cost and score provenance. Master, senior and junior are role assignments. A ticket may select a concrete model; otherwise it uses the role default.
  2. Blended list cost weights input to output at 3:1. Subscription effective cost uses a default ×0.1 factor for routing. It is a policy weight, not an invoice or a savings claim. score_source distinguishes rated, estimated and unknown.
  3. Ledger projects impose provider-and-role eligibility: validated, verify or excluded. Restricted work needs an eligible validated verifier from another family; the platform reroutes or holds when that condition cannot be met.
  4. Outside mandatory restrictions, a single-family verification must be labeled as such. A second run from the same family is not represented as an independent family opinion.

05 · Secrets

What the secrets filter protects — and what it cannot.

It protects the passwords and keys you have stored as secrets in the project: CodeHero knows those values and keeps them away from the AI. It cannot recognise a password it was never told about — for example one you type into a message or that shows up in a screenshot. So store every password as a secret; never paste it into a chat.

What the AI sees

The secrets filter: what it protects and what it cannotA password stored as a secret: the filter knows it and replaces it, so the AI sees only «secret withheld». A password typed into a message or visible in a screenshot: the filter was never told about it, so the AI sees it. So: store every password as a secret and never paste one into a chat.Stored as a secreta password in the project’s secretsSecrets filterknows it — hides itThe AI sees[secret withheld]Typed in a messageor shown in a screenshotSecrets filterwas never told about itThe AI seesthe passwordThe secrets filter: what it protects and what it cannotA password stored as a secret: the filter knows it and replaces it, so the AI sees only «secret withheld». A password typed into a message or visible in a screenshot: the filter was never told about it, so the AI sees it. So: store every password as a secret and never paste one into a chat.Stored as a secreta password in the project’s secretsSecrets filterknows it — hides itThe AI sees[secret withheld]Typed in a messageor shown in a screenshotSecrets filterwas never told about itThe AI seesthe password
Store every password as a secret — then the AI never sees it.
Read the diagram as text
  1. A password stored as a secret: the filter knows it and replaces it, so the AI sees only «secret withheld».
  2. A password typed into a message or visible in a screenshot: the filter was never told about it, so the AI sees it.
  3. So: store every password as a secret and never paste one into a chat.
How it works underneath

Declared secrets meet a boundary

Declared secrets meet a boundaryThe filter collects protected values from project secret locations and the platform’s known provider credentials. Typed fields distinguish secrets from visible settings. Input checks refuse writes containing a protected value. Output containing a value is blocked, or replaced with named placeholders for explicitly masked commands. Agent text is also checked before database persistence. Values shorter than 8 characters are not matched. Collection limits include 1 MiB per file, 200 files, 200 lines in a free-text template and 5,000 values. The filter does not discover or relocate every possible credential.Declared projectsecrets+ platform credentialsKnown-value collectionTool input checkrefuse protected writesTool executionOutput filterblock / maskModel receivesfiltered outputDeclared secrets meet a boundaryThe filter collects protected values from project secret locations and the platform’s known provider credentials. Typed fields distinguish secrets from visible settings. Input checks refuse writes containing a protected value. Output containing a value is blocked, or replaced with named placeholders for explicitly masked commands. Agent text is also checked before database persistence. Values shorter than 8 characters are not matched. Collection limits include 1 MiB per file, 200 files, 200 lines in a free-text template and 5,000 values. The filter does not discover or relocate every possible credential.01Declared project secrets+ platform credentials02Known-value collection03Tool input checkrefuse protected writes04Tool execution05Output filterblock / mask06Model receivesfiltered output
Protection depends on known, declared values. An arbitrary credential pasted into chat is outside this guarantee.
Read the diagram as text
  1. The filter collects protected values from project secret locations and the platform’s known provider credentials. Typed fields distinguish secrets from visible settings.
  2. Input checks refuse writes containing a protected value. Output containing a value is blocked, or replaced with named placeholders for explicitly masked commands. Agent text is also checked before database persistence.
  3. Values shorter than 8 characters are not matched. Collection limits include 1 MiB per file, 200 files, 200 lines in a free-text template and 5,000 values. The filter does not discover or relocate every possible credential.

06 · Memory folding

Like a desk
with a drawer.

An AI can only keep so much in front of it at once. On a long job — dozens of files, test runs, reports — that space fills up, and an AI that runs out of room slows down, costs more and starts to miss details. CodeHero’s agent works like a person at a desk: when it has finished with a long report, it writes a short note of what matters, puts the report away in a drawer and keeps only the note in front of it. Nothing is thrown away — if it needs a detail later, it opens the drawer. So it can work much longer, keep the thread, and spend less reading the same things again.

The desk and the drawer

Memory folding: a short note on the desk, the full report in the drawerThe agent finishes with long results: a report, a test run, a big file. It writes a short note of what matters and keeps only the note on its desk. The full reports go into the drawer, unchanged. If it needs a detail later, it opens the drawer.Long reportTest runBig filefoldsOn the deskShort notewhat matters, in its own wordsThe drawerevery report kept in fullneed a detail? opens the drawerMemory folding: a short note on the desk, the full report in the drawerThe agent finishes with long results: a report, a test run, a big file. It writes a short note of what matters and keeps only the note on its desk. The full reports go into the drawer, unchanged. If it needs a detail later, it opens the drawer.Long reportTest runBig filefoldsShort notewhat matters, in its own wordsThe drawerevery report kept in fullneed a detail? opens the drawer
Less to carry on every step — nothing lost.
Read the diagram as text
  1. The agent finishes with long results: a report, a test run, a big file.
  2. It writes a short note of what matters and keeps only the note on its desk.
  3. The full reports go into the drawer, unchanged. If it needs a detail later, it opens the drawer.
How it works underneath

Keep the original. Read the note.

Keep the original. Read the note.Large tool results receive references. The agent can fold multiple refs with a note and unfold a ref to recover the original. Identity comes from stored metadata, not a quoted reference in content. The API agent sees the folded rendering on its next request within the run. CLI history reflects it when rebuilt for the next run; list=true exposes refs during the run. A CLI session is not retroactively rewritten. The database retains the unchanged original. Completion gates, reviewers and verifiers read that original. Folding is a context-management mechanism, not a promise of perfect memory.Tool result + refOriginal in databaseAgent folds refswith a noteRendered contextnote + referenceUnfold by refReviewer / verifierreads originalKeep the original. Read the note.Large tool results receive references. The agent can fold multiple refs with a note and unfold a ref to recover the original. Identity comes from stored metadata, not a quoted reference in content. The API agent sees the folded rendering on its next request within the run. CLI history reflects it when rebuilt for the next run; list=true exposes refs during the run. A CLI session is not retroactively rewritten. The database retains the unchanged original. Completion gates, reviewers and verifiers read that original. Folding is a context-management mechanism, not a promise of perfect memory.01Tool result + ref02Original in database03Agent folds refswith a note04Rendered contextnote + reference05Unfold by ref06Reviewer / verifierreads original
Folding changes what is rendered to the agent. It does not rewrite the stored result.
Read the diagram as text
  1. Large tool results receive references. The agent can fold multiple refs with a note and unfold a ref to recover the original. Identity comes from stored metadata, not a quoted reference in content.
  2. The API agent sees the folded rendering on its next request within the run. CLI history reflects it when rebuilt for the next run; list=true exposes refs during the run. A CLI session is not retroactively rewritten.
  3. The database retains the unchanged original. Completion gates, reviewers and verifiers read that original. Folding is a context-management mechanism, not a promise of perfect memory.

07 · Safe upgrades

No work starts in the middle of an upgrade.

While CodeHero itself is being upgraded, its new program can be in place before the database has been updated to match it. So during an upgrade no new work starts. Work already running finishes normally, and waiting work starts right after.

During an upgrade

Safe upgrade: no new work starts until the upgrade is completeThe upgrade starts by saving a copy of the installation. While the new program is copied in and the database is updated, no new work starts. Work that was already running finishes normally. When the upgrade is done, waiting work starts right away.Upgrade startsa copy is saved firstNo new work startsnew program in · database updatedUpgrade donewaiting work startsWork already running finishes normallySafe upgrade: no new work starts until the upgrade is completeThe upgrade starts by saving a copy of the installation. While the new program is copied in and the database is updated, no new work starts. Work that was already running finishes normally. When the upgrade is done, waiting work starts right away.Upgrade startsa copy is saved firstNo new work startsnew program in · database updatedUpgrade donewaiting work startsWork already running finishes normally
The program and the database always match when work starts.
Read the diagram as text
  1. The upgrade starts by saving a copy of the installation.
  2. While the new program is copied in and the database is updated, no new work starts.
  3. Work that was already running finishes normally. When the upgrade is done, waiting work starts right away.
How it works underneath

Hold new starts during an upgrade

Hold new starts during an upgradeupgrade.sh writes an upgrade marker before replacing files. The daemon checks that marker before both ordinary and forced starts. Existing running tickets continue. The marker is removed after migrations and settings are in place at step 8. A marker older than one hour is ignored, allowing recovery from a killed upgrade; an interrupted upgrade still needs operator investigation.Upgrade beginscreate markerNew starts heldrunning work continuesMigrations + settingsRemove markernew work resumesHold new starts during an upgradeupgrade.sh writes an upgrade marker before replacing files. The daemon checks that marker before both ordinary and forced starts. Existing running tickets continue. The marker is removed after migrations and settings are in place at step 8. A marker older than one hour is ignored, allowing recovery from a killed upgrade; an interrupted upgrade still needs operator investigation.01Upgrade beginscreate marker02New starts heldrunning work continues03Migrations + settings04Remove markernew work resumes
The 5.0.2 interlock prevents newly started work from seeing code ahead of its schema.
Read the diagram as text
  1. upgrade.sh writes an upgrade marker before replacing files. The daemon checks that marker before both ordinary and forced starts. Existing running tickets continue.
  2. The marker is removed after migrations and settings are in place at step 8. A marker older than one hour is ignored, allowing recovery from a killed upgrade; an interrupted upgrade still needs operator investigation.

08 · Going back safely

Before going back, it keeps a copy of now.

You can return a project to an earlier state — from a quick copy on the server or from a backup. Before it restores, CodeHero saves the current state first, so a restore can itself be undone.

Before an in-place restore

Before an in-place restoreSafety copy. Restore selected state. Check the application.01Safety copy02Restore selected state03Check the applicationBefore an in-place restoreSafety copy. Restore selected state. Check the application.Safety copyRestore selected stateCheck the application
If the safety copy fails, the restore stops.
Read the diagram as text
  1. Safety copy.
  2. Restore selected state.
  3. Check the application.
How it works underneath

A restore starts with a safety copy

A restore starts with a safety copyQuick ZIP includes files and databases, including container databases. Full adds service configuration and port forwards. Complete also includes tickets, conversations and the knowledge graph. The manifest reports unreadable files or failed database dumps. Editable exclusions apply to manual ZIP levels; secrets are excluded by default. A partial ZIP is not listed as a completed backup. An in-place restore first takes a safety copy: a container snapshot where applicable and a complete ZIP. If the copy cannot be made, restore stops. Image import takes the ZIP first because it replaces the container snapshots too. Retention, off-server copies, credentials and checking the restored application remain operating responsibilities. A successful archive operation alone does not prove recovery readiness.Choose backupinspect warningsSafety snapshot+ complete ZIPSafety copy failedstop restoreRestore selected stateCheck services + dataA restore starts with a safety copyQuick ZIP includes files and databases, including container databases. Full adds service configuration and port forwards. Complete also includes tickets, conversations and the knowledge graph. The manifest reports unreadable files or failed database dumps. Editable exclusions apply to manual ZIP levels; secrets are excluded by default. A partial ZIP is not listed as a completed backup. An in-place restore first takes a safety copy: a container snapshot where applicable and a complete ZIP. If the copy cannot be made, restore stops. Image import takes the ZIP first because it replaces the container snapshots too. Retention, off-server copies, credentials and checking the restored application remain operating responsibilities. A successful archive operation alone does not prove recovery readiness.01Choose backupinspect warnings02Safety snapshot+ complete ZIP03Safety copy failedstop restore04Restore selected state05Check services + data
A snapshot supports local rollback. A backup supports recovery of the included state. Both need a checked restore procedure.
Read the diagram as text
  1. Quick ZIP includes files and databases, including container databases. Full adds service configuration and port forwards. Complete also includes tickets, conversations and the knowledge graph.
  2. The manifest reports unreadable files or failed database dumps. Editable exclusions apply to manual ZIP levels; secrets are excluded by default. A partial ZIP is not listed as a completed backup.
  3. An in-place restore first takes a safety copy: a container snapshot where applicable and a complete ZIP. If the copy cannot be made, restore stops. Image import takes the ZIP first because it replaces the container snapshots too.
  4. Retention, off-server copies, credentials and checking the restored application remain operating responsibilities. A successful archive operation alone does not prove recovery readiness.

Hosting

After delivery, it keeps running.

Each application gets its own space on the server, with its own database and tools, an address with a secure connection, protection and backups. These are capabilities of the platform; a hosted service with agreed terms is discussed separately.

One project from domain to recovery

One project from domain to recoveryA production domain and SSL certificate lead to nginx routing. nginx sends requests to the project container, which runs the application and database services. Backups preserve the selected project state; snapshots provide local rollback. Later maintenance reuses the same project record.Domain + SSLnginx routingProject containerApp + databaseBackups + historyOne project from domain to recoveryA production domain and SSL certificate lead to nginx routing. nginx sends requests to the project container, which runs the application and database services. Backups preserve the selected project state; snapshots provide local rollback. Later maintenance reuses the same project record.Domain + SSLnginx routingProject containerApp + databaseBackups + history
Per-project services; explicit deployment and recovery boundaries.
Read the diagram as text
  1. A production domain and SSL certificate lead to nginx routing. nginx sends requests to the project container, which runs the application and database services. Backups preserve the selected project state; snapshots provide local rollback. Later maintenance reuses the same project record.

Per-project execution

LXC project environments and service lifecycle management. The catalog includes PHP, Node.js, Python, Java, .NET, Go and Ruby; MySQL, MariaDB, PostgreSQL, MongoDB and Redis. Version availability is installation-dependent.

Production routing and SSL

Project deployment routes a configured domain to its web path or container IP. Certificate upload, certificate matching, issuance and renewal controls are present. DNS and reachability remain deployment inputs.

Firewall scope

Optional ModSecurity setup with OWASP CRS protects configured dashboard and web-project entry points. Network firewall rules are documented operator commands. This is not evidence of a general per-project firewall UI or automatic WAF coverage for every production domain.

Backup, snapshot and restore

ZIP levels cover files, databases, service configuration and, at Complete level, tickets, conversations and knowledge. BTRFS snapshots support local rollback. Database preparation is best effort: if a pre-snapshot hook fails, the snapshot can proceed as crash-consistent. Off-server copies and restore validation remain operational work.

Upgrades and later maintenance

Platform upgrades set an interlock to hold new ticket starts until schema and settings match. Existing-project planning reads map.md, technologies.md, the knowledge base and specifications before new work. Small fixes use a normal build ticket and the light verification loop.

Knowledge

The project keeps its own memory.

Decisions, patterns, bugs and approaches that failed are stored with the project and linked to the work they came from, so the next piece of work — or the next person — can find them.

  1. Rules + decisions + reasons
  2. Project database + files
  3. Next ticket / person / model

This is persisted, retrievable project knowledge. It depends on the records actually being written, their accuracy and the context selected for the next task. It does not mean every model sees the entire history or that undocumented intent is captured automatically.

Questions people ask

All the articles
Am I tied to one AI company?

No. CodeHero works with many AI companies at once and with models on your own hardware. You can change company or model at any time — the project, its rules and its history stay. Read the article

Do my passwords and keys reach the AI company?

No. Passwords and keys you store as secrets are used by your application, but their values are never sent to the AI service. Read the article

Why do several AIs work on the same job?

Because one AI does not catch its own blind spots. In CodeHero one model builds and a model from a different company checks; problems go back for repair and are checked again. Read the article

How does CodeHero compare with other AI coding tools?

It is a different kind of thing. Coding tools help a person who writes code. CodeHero does the whole job — asks, plans, builds, checks, hosts and maintains — for the person who knows the business. Read the article

If CodeHero writes the code, what is my role?

You become the advisor: you decide the business rules, approve the plan and accept the result. CodeHero is the developer that asks, builds, checks and maintains. Read the article

How does the AI keep its memory on long jobs?

With memory folding: when the AI has finished with a long result it keeps a short note of what matters and puts the rest away — it can open it again at any time. So it works much longer without losing the thread. Read the article

How does the AI avoid forgetting or getting confused on a big project?

The factory gives it structure: smart tickets with one clear job each, a change ledger of every decision, a map of the code and search by meaning. The AI reads what it needs instead of guessing — which also saves a lot of cost. Read the article

Why do you call it a factory and not a tool?

Because it runs the whole production line on its own — planning, building, independent checking, repair, delivery and maintenance — with stations, rules and records, like a factory. A tool waits for a person to use it. Read the article

How can this change the world of applications?

When the person who knows the work can get software made, checked, hosted and maintained without a development team, software can be made for every business and every need — not only for those that can afford a team. Read the article

What does CodeHero mean for developers?

Less repetitive work and fewer late nights. The factory takes the routine building, checking and fixing; developers decide the architecture, review what matters and handle the hard problems. Read the article

Why does CodeHero host the applications too?

Because building and running belong together. The application runs where it was built, with its domain, secure connection, backups and recovery — and every later change returns to the same factory. No separate hosting panel to learn. Read the article

What technology do the applications use?

Always open, widely used technologies — PHP and MySQL first, and others such as Node, Python or .NET when the job needs them. Your application is never locked into a proprietary platform. Read the article

Why use AI subscriptions instead of paying per use?

Because in our own measurements, for heavy daily work, a subscription has cost up to about 40 times less than paying per use for the same work. CodeHero runs the subscription AI tools (Claude Code, Codex, Grok Build) as workers in the factory. Read the article

What happens to the knowledge about my project?

It is built up and kept inside your installation: decisions, rules, changes and their reasons, next to the code. A new person or a new AI continues from there — the knowledge does not leave with them. Read the article

Can small local AI models do real work?

Inside the factory, yes — more than on their own. Small, clear tickets, a checklist for finishing, tool help and a stronger model that checks the result let small models on your own hardware do much of the building. Read the article