01
Single-tenant delivery mode
- Best for formal enterprise customer delivery
- Needs a dedicated access URL
- Needs complete isolation from other customers
- One customer, one tenant, with clear data and capability boundaries
Deployment
Deployment
Deployment ThesisThe control plane can stay unified, while the execution location does not have to.
That is exactly why ExecGov can currently support formal delivery, public experience, and local onboarding at the same time.
ExecGov is not built around a single deployment model. It composes options according to data boundaries, customer scale, and execution location. The goal is not to force every user down one path, but to cover multiple real deployment shapes with one governance logic.
From a public point of view, the more stable ladder right now is: the free path, lightweight local script-slot expansion, the formal shared-SaaS team edition, enterprise single-tenant / private delivery, with local hybrid execution layered on top when needed.
Single-tenant deliveryPlatform governanceFree public entryLocal hybrid execution
EXECGOV // DEPLOYMENT MATRIXDOC 05
const enterpriseMode = 'single_tenant_delivery'const platformMode = ['public_governance', 'free_entry']const hybridMode = ['local_execution', 'cli_bridge']
ONE GOVERNANCE / MULTIPLE DEPLOYMENTS
02
Platform governance mode
- The platform side manages multiple customers centrally
- Needs unified control over announcements, templates, logs, and ledgers
- Needs cross-tenant governance without breaking tenant isolation
publicacts as the governance domain
03
Free-entry mode
- Fits product experience and the personal developer free path
- Emphasizes onboarding speed and the experience path
- Acts as the front door for later deeper discussion and formal delivery
Path To Deployment
How to understand deployment across the four paths
| Current layer | Best-fit deployment interpretation | Current focus | Signal for the next step |
|---|---|---|---|
| Free path | Use the public experience, login / signup, and personal entry to understand the platform first | Confirm that the execution chain, product position, and entry experience are real | If usage becomes continuous, move into the personal entry or evaluate local script slots next |
| Local script-slot expansion | Lightweight personal-space expansion without changing the overall deployment shape | Solves the problem of continuing personal script onboarding and is not the same thing as formal team delivery | If multi-user collaboration begins, move into standard-team evaluation |
| Standard team edition | Shared-SaaS formal tenant entry first | Fits standard capability, lighter collaboration, and teams that do not need deep frontend customization | If stronger isolation, dedicated pages, or formal acceptance is needed, move into enterprise delivery |
| Enterprise delivery | Single-tenant delivery, private deployment, or deeper deployment control | Fits intranet work, stronger isolation, custom branding, or formal project delivery | If local environments or intranet resources are also involved, layer on hybrid execution |
04
Local hybrid execution mode
- Fits cases where files and data cannot all move into the cloud
- Fits tasks that depend on local environments or intranet resources
- The platform owns entry, planning, permission, and audit
- The local environment owns execution, while the CLI / Agent path owns bridging
05
Paths outside the current public focus
- The current public focus is not device, edge, or plugin governance
- Long-running Agent execution still belongs to later enhancement rather than today's main public selling point
- Getting local execution and intranet onboarding right inside real projects matters more right now
- More distant routes should open only when real demand justifies them
Shared SaaS
Standard shared-SaaS tenant mode
How it runs today
From tenant_1003+ onward, standard SaaS customers first enter the shared-tenant frontend skeleton. Runtime still binds schemas by Host, so tenant isolation remains real rather than collapsing all customers into one shared backend account.
What it fits best
It fits standard capability, lighter team collaboration, and scenarios that do not require deep frontend customization. If a customer needs heavier isolation, dedicated pages, custom branding, or deeper deployment control, the work should move into single-tenant delivery or private deployment.
- What is shared is the frontend project and formal release rhythm, not tenant data, accounts, or permissions
- Standard SaaS customers still use capabilities, menus, announcements, and result entries inside their own tenant space
- The shared-tenant frontend already exists, but tenant-specific branding and finer deployment parameters are still being tightened
Upgrade Path
The more realistic upgrade ladder from public entry to formal delivery
| Stage | Current state | Best-fit deployment interpretation | Signal for the next step |
|---|---|---|---|
| 01. Public experience phase | Start with the public experience page, login page, signup page, and docs site | The focus here is not private deployment first. It is whether the execution chain, product position, and entry experience are real. | If the user wants repeated use, move into the personal entry or continue with local script slots / the team path |
| 02. Personal free-entry phase | The user has already entered the free entry and is starting to understand the execution console, AI execution, and baseline usage | This phase is closer to product experience and growth entry than to formal team or enterprise delivery | If the user only wants to keep onboarding scripts personally, evaluate local script slots first. If multi-user collaboration becomes important, move into team evaluation. |
| 03. Personal expansion phase | The user is continuously onboarding scripts personally but has not entered multi-user collaboration yet | The focus is personal-space expansion and local onboarding, not enterprise deployment language | If multi-user collaboration, permission control, and formal account management appear, move into the standard team edition |
| 04. Standard team phase | The customer is evaluating whether standard collaboration, permission control, and menu needs are enough | Shared-SaaS formal tenant entry should be evaluated before defaulting into single-tenant or private deployment | If the customer needs a dedicated URL, custom pages, or formal acceptance, move into enterprise delivery |
| 05. Formal delivery phase | The customer needs its own access address, its own capability boundary, and a formal delivery package | Two realistic paths currently exist: the standard shared-SaaS tenant path and enterprise single-tenant delivery. The first is more standardized; the second is better for deeper isolation and customization. | If the need is mostly standard collaboration and standard menus, prefer shared SaaS first. If a dedicated environment and heavier customization are required, move into single-tenant delivery. |
| 06. Local expansion phase | The task starts depending on local environments, intranet resources, or private data | Layer local hybrid execution on top of single-tenant delivery or platform governance, with the CLI / Agent path handling the bridge | If the next question is which standard product tier this belongs to, continue into Editions |
Upgrade Signal
Signals that it is time to move beyond the free entry into formal delivery
- The customer needs its own formal access URL
- The customer needs a dedicated tenant and stricter data / capability isolation
- The customer needs formal accounts, permissions, acceptance, and update notes
- The customer needs to onboard real script capabilities, real business scenarios, and real approval boundaries
- The platform needs to become a sustained delivery space instead of only an experience entry
Recommended Path
Common upgrade path
- The free path fits product and execution-chain experience first
- If the need is still only personal continued usage, start with lightweight local-script-slot expansion
- The standard team edition fits multi-user collaboration, formal tenants, and a steadier usage cycle
- Formal delivery fits cases that need a dedicated URL, tenant isolation, and long-term use
- Standardized small-team capability and richer package options will continue to expand
- The common ladder is to start free, then move gradually through local script slots, the team edition, or enterprise delivery
Deployment Prep
Three things that are usually aligned before deployment evaluation
FilesFiles & Results
If the project depends on input files, batch status, Excel outputs, or exported artifacts, clarify the file flow first before talking about deployment modes.
DeliverablesDeliverablesFormal delivery evaluation usually starts with a concrete definition of which URL, account, instructions, and result entry the customer will finally receive.
ChecklistOnboarding ChecklistIf the real script capability and real scenario already exist, prepare the script directory, README, example files, dependencies, and risk boundaries first. Deployment decisions become much easier after that.
Standard Delivery
Standard delivery package
- An isolated tenant
- A dedicated access URL
- A set of customer-specific capabilities, currently usually script-shaped capabilities first
- Platform accounts and baseline permissions
- Customer usage notes and script hot-update notes
Standard Scope
What is not included by default today
- A public third-party capability marketplace
- Customer-side script publishing that bypasses the platform
- Tenant-side upload of arbitrary Vue / JS as formal frontend pages
- Approval-free high-risk automatic execution
- Cross-customer capability sharing that breaks tenant boundaries
Menu Boundary
Menu customization boundary
- Customers can attach existing pages through the database menu
- Customers can attach external links or iframe entries
- If the project needs a brand-new page that does not exist in the current frontend package, it still requires formal frontend development, packaging, and deployment
- Shared SaaS does not allow tenants to upload arbitrary frontend code and convert it directly into formal product pages
How To Choose
Choose the right deployment path by project focus
Customer DeliveryCustomer-delivery projects
Start with the single-tenant delivery path first, then add unified governance if the operating model requires it.
Platform OpsPlatform governance and operationsLayer platform-governance mode on top of tenant isolation so announcements, templates, logs, and ledgers can be centrally controlled.
Delivery OpsCustomer go-live and post-launch update flowGo directly to Customer Flow / Delivery to understand the formal delivery package, usage path, hot updates, and acceptance priorities in one view.
File FlowIf the project's core is file processing and result artifactsClarify public input-file upload, batch status, and result-download flow first, then decide whether the work belongs in cloud execution or hybrid execution.
Delivery KitFormal delivery package and long-term customer entryContinue into the Deliverables page to define the real instructions and entries the customer will use over time.
Growth EntryFree path and lead-routing entryLet visitors enter through the free path first, then decide whether they should remain in personal space, move into the team edition, or continue into enterprise delivery.
CLI BridgeLocal environments and intranet executionStart with the CLI Guide and validate the current boundary of login / register / run / agent before attaching local bridging to the deployment plan.
Return to the Onboarding Checklist first instead of forcing an early label such as private deployment, platform governance, or local bridge.
Current StageCurrent stage and next prioritiesReturn to Editions first to confirm what is real today and what still should not be oversold.