Repository navigation
User Guide: Managing Custom Apps
After deploying a custom application via My Apps, you can manage it with restart, rebuild, high-availability, and custom domain features. This guide covers the operational features available for deployed apps.
When your application needs updating, you have two options. Restart is the default and recommended approach for deploying new code. It is faster because it reuses the build cache. Only use rebuild when you specifically need to clear caches.
A restart pulls the latest code from your git repository and restarts the application container. It reuses the existing build and dependency cache (e.g. node_modules) if the lockfile has not changed. This makes restarts significantly faster than rebuilds.
Use restart when:
- You pushed new code to your repository (this is the most common case)
- You changed configuration values in the parameter store
- The application is stuck or unresponsive
A rebuild fully recreates the application instance from scratch. It deletes the running instance and creates a new one, clearing all caches and rebuilding from the latest source code and container image. This is slower than a restart because no caches are reused.
Warning: Without High Availability, the app is stopped and removed before the new build starts, so a failed rebuild leaves the app down. With High Availability (Node.js and Python apps on a paid plan), the old version keeps serving during a rebuild. The Recreate app option in the update dialog shows this warning.
Note: When rebuilding via the
restart-my-appMCP tool, any parameter store (ConfigService) binding is automatically preserved and re-applied to the new instance.
Only use rebuild when:
- You changed
package.json(or equivalent) dependencies and the cached node_modules are stale - You need to pick up a new base image or runtime version
- A restart did not resolve your issue (rebuild as a last resort)
- Your app with a parameter store (ConfigService) fails to load environment variables with an expired token error (apps created before 2026-02-25 used short-lived tokens — a rebuild migrates them to a long-lived refresh token). Note: you can also use the Config button or
update-my-app-configMCP tool to re-bind the parameter store without a full rebuild.
Security scan on rebuild: Every rebuild automatically triggers a Trivy vulnerability scan of your application image. The scan result appears in the Security tab of your app detail page. This happens in the background and does not delay the restart flow.
Via the Web Console:
- Go to My Apps
- Click the update (refresh) icon on your application card
- Choose Restart or Rebuild in the dialog
- Click Confirm
Via MCP (AI Agent):
"Restart my app called myapp"
"Rebuild my app called myapp"
The MCP create-my-app tool and CLI support both operations.
By default, restarts and rebuilds pull the latest commits from your repository's default branch. You can pin your app to a specific branch, tag, or commit SHA to lock deployments to a known-good version or to deploy from a feature branch.
Via the Web Console:
- Go to My Apps
- Click on your application to open the detail page
- Click the Settings tab
- Scroll to the Git ref section
- Enter a branch name, tag, or commit SHA in the input field (e.g.
v1.2.3,feature/my-branch,abc1234) - Click Pin to ref
The Settings tab shows "Pinned to <ref>" once saved. Future restarts and rebuilds pull from that ref instead of the default branch head.
- Open the Settings tab for your app
- Clear the Git ref input field
- Click Unpin
The app returns to following the latest commits on the default branch.
| Type | Examples |
|---|---|
| Branch |
main, develop, feature/my-feature
|
| Tag |
v1.2.3, release-2025-01
|
| Commit SHA |
abc1234, full 40-character SHA |
The field accepts letters, numbers, dots, hyphens, underscores, and slashes. Spaces and special characters are not allowed.
HA mode runs two instances of your application in a blue-green configuration. It makes restarts and rebuilds of your app safe to do while it serves traffic. It does not switch traffic automatically when a running instance fails (see "What HA does not cover" below).
When HA is enabled, OSC maintains two copies of your application:
- Active: the instance currently serving traffic
- Standby: a warm standby ready to take over
When you restart or rebuild with HA enabled, only the standby is updated first. Once the standby passes health checks, traffic is switched to it, so the version that was serving keeps serving until the new one is ready.
The update flow:
- The standby instance is restarted (or rebuilt)
- OSC polls the standby's
/healthzendpoint until it responds with HTTP 200 - The proxy switches traffic from the active to the standby
- The previously active instance becomes the new standby
The two instances are called slot a (your app, myapp) and slot b (myappb), but the roles are not tied to a slot. Every restart or rebuild swaps them, so the active instance is sometimes slot a and sometimes slot b. Run get-my-app on your app to see which slot is active right now.
get-my-app for the standby myappb reports HA Mode: slot b of myapp; HA is enabled on myapp (active slot: ...). If it reports HA Mode: Disabled for myappb instead, HA is off on myapp or myapp could not be read. The HA setting lives on the primary, so run get-my-app for myapp to see the real state.
Note: HA is only available for Node.js and Python apps on paid plans.
Only a restart or a rebuild of an HA app waits for the standby to be healthy before traffic moves. No other change is described as zero-downtime here.
Changes that are not a restart or a rebuild are not covered by that check. These are config service updates, analytics service updates, changing the source ref, and changing the Git token. Each is applied to both instances one after the other, without waiting for the other instance to be healthy, and each change rolls the pod of the instance it is applied to. Source ref and Git token changes also restart both instances. Expect your app to be briefly unavailable during such a change, and do not rely on HA to prevent it.
- A failed active instance. If the active instance is evicted, killed for running out of memory, or crashes, OSC does not move traffic to the other instance. The other instance keeps running, but traffic stays on the failed one until its pod is back. An app built from a Git repository clones and builds again on every start, so this takes about two minutes.
- A running but unresponsive app. If the pod is up but your app does not answer, nothing switches traffic.
- A platform-wide outage. Both instances run on the same platform.
A wildcard custom-domain mapping (*.example.com) stays on the instance it was created for, which is the app's first instance. A restart or rebuild swaps the app's own domain and its other custom-domain mappings to the standby (see "Enabling HA" below), but it does not move the wildcard mapping. Wildcard traffic can therefore be interrupted while that first instance is rebuilt.
Via the Web Console:
- Go to My Apps
- Find your application card
- Toggle the HA switch to enable it
- The standby instance is created automatically with the same configuration as your active instance
Via MCP (AI Agent):
"Enable HA for my app called myapp"
Name reservation: The standby of an app named
myappis calledmyappb. If an instance with that name already exists, enabling HA is refused with a message and no standby is created. If HA is already enabled, the message says so. The standby is hidden from your app list while HA is enabled for the primary.
Enabling HA creates the standby from the configuration of your running app and sets the HA flag. It does not rebuild or restart the instance that serves traffic, and it does not change ingress or domains. Because the two instances are built from the same source at different times, they can run different versions until the first restart with rebuild=true. Run one right after enabling HA so both slots are on the newest code.
Custom domains you have already added follow the active instance on each swap, so there is no need to add them again. The one exception is a wildcard mapping, described in "Wildcard domains and HA" above.
Before you disable: disabling HA removes slot b, the standby myappb. If slot b is the active instance at that moment, traffic is switched back to slot a without a health check, and slot a can be running an older version than the one that was live on slot b. To avoid that, first run get-my-app for your app and read the HA Mode line.
- If it shows
HA Mode: Enabled (active slot: a), you can disable HA right away. - If it shows active slot
b, runrestart-my-appwithrebuild=true. That updates slot a and then makes it the active one. Runget-my-appagain, confirm it now showsHA Mode: Enabled (active slot: a), and then disable HA.
Via the Web Console:
- Go to My Apps
- Toggle the HA switch off
- The standby instance is removed
Via MCP (AI Agent):
"Disable HA for my app called myapp"
After disabling HA, the AI agent will note that the secondary instance (named appnameb) may still be running if it was created on a different infrastructure cluster before a platform migration. To verify cleanup:
"Diagnose orphan app myappb"
If the secondary is still running, diagnose-my-app-orphan tells you whether it is a live part of an HA pair or a leftover. Only a leftover should be deleted, as described under "HA secondary orphans" in the troubleshooting section below.
- Supported runtimes: HA mode is available for Node.js (web-runner) and Python (python-runner) apps. It is not currently supported for WASM, Go, or .NET runners.
- Your application must expose a
/healthzendpoint that returns HTTP 200 when the app is healthy. OSC uses this to determine when the standby is ready to receive traffic. - HA mode requires a paid plan (Personal, Professional, Business, or Enterprise). The HA toggle is disabled for FREE plan accounts with a tooltip explaining the requirement.
- HA mode creates a second instance, which counts as an additional service instance for billing purposes.
When HA is enabled, the standby instance receives an exact copy of the active instance's configuration, including:
- Git repository URL
- Access token (for private repos)
- Parameter store (ConfigService) configuration
- OSC access token
- Sub-path (for monorepo deployments)
Any future configuration changes should be applied by updating the active instance and then restarting (which triggers the blue-green update flow).
My Apps do not scale to zero. A running app maintains at least one warm pod at all times (at least two in HA mode). The first request after an idle period hits a live process, so there is no cold start for normal apps.
There is no autoscaler or scale-to-zero mechanism. Replica count stays fixed at 1 (non-HA) or 2 (HA) regardless of traffic volume.
Exception — Suspended apps: A suspended app has 0 replicas and is not serving traffic. When you resume a suspended app, Kubernetes must start a new pod, which takes roughly 10–30 seconds depending on the image size. Users who suspend their app between uses will experience this startup delay on resume.
Via MCP (AI Agent):
"Suspend my app called myapp"
"Resume my app called myapp"
Suspension is reversible. Only the running pod is stopped — configuration, parameter store bindings, and git ref settings are all preserved.
Note: On the Free plan, resuming a suspended app is blocked once your token balance is zero or negative, the same as creating a new app — see Pricing. Upgrade to a paid plan to resume.
You can invite external collaborators to your app. Collaborators get their own Gitea account scoped to your repository — they can clone, browse, and open issues without sharing your admin credentials. They also have access to the Collaborator Portal, a lightweight web interface where they can submit feature requests and bug reports and track the status of their submissions.
Via the Web Console:
- Go to My Apps and open the detail page for your app.
- Click the Collaborators tab (last tab on the detail page).
- Click Invite collaborator.
- Enter the collaborator's email address and click Invite.
- The modal shows a copyable invite URL. Send this URL to the collaborator — it includes their email address so the portal login form is pre-filled when they follow the link.
After an invite is sent, the collaborator appears in the table with status Pending until they accept. Once accepted the status changes to Active.
The Collaborator Portal is a self-contained web UI at https://app.osaas.io/collab/{appId} that lets external contributors interact with your app's SDLC without an OSC account.
Collaborators log in with the email address their invite was sent to. Once logged in they can:
- Submit new feature requests and bug reports
- View a live list of their submitted tickets with status labels (Queued, Planning, Working on it, In review, Shipped, Needs your input)
The ticket list polls for updates every 5 seconds while the tab is visible, so collaborators see progress in real time without refreshing. Submissions also appear in your app's Requests tab (in the Agentic SDLC view) alongside requests created by the agent, labelled as sdlc/source:collaborator.
The icon button next to each collaborator in the table adapts based on their status:
- Pending collaborators show a Resend invite button (envelope icon). Use this if the collaborator never received or lost their original invite link. A new invite URL is generated and shown — copy it and send it to them.
- Active collaborators show a Reset access link button (key icon). Use this to rotate the collaborator's portal access link, for example after a suspected compromise. A fresh URL is generated; the old one is invalidated immediately.
In both cases the new URL is displayed in a modal after the action completes.
| Status | Meaning |
|---|---|
| Active | Collaborator has accepted the invite and their Gitea account is active |
| Pending | Invite sent but not yet accepted |
| Revoked | Access has been removed |
Click the Revoke button next to an active or pending collaborator. Confirming the revocation deactivates their Gitea account and removes their repository access immediately.
Note: Collaborator access requires Agentic SDLC to be enabled for the app, which provisions the managed Gitea repository that collaborators access.
The My Apps dashboard shows real-time build and runtime status for each deployed application in the URL column:
| Status | Description |
|---|---|
| Building... | The application is currently being built or deployed |
| (URL link) | The application is running and accessible |
| Build failed | The last build failed — check logs for details |
| Startup failed | The app deployed successfully but failed to start — it likely crashed at startup |
When a build fails, the URL column shows a red "Build failed" message with a "Check logs for details" hint.
Crash-at-startup detection: If an app stays in "Building..." for more than 2 minutes after a restart or rebuild, OSC automatically detects this as a likely crash-at-startup and shows a "Startup failed" status with the message "App failed to start — it may have crashed at startup. Check the app logs." Use the View logs action to diagnose the issue. Click Dismiss to clear the error state once you have investigated. Common causes include missing environment variables, a misconfigured start command, or a runtime error thrown on boot. Use the Viewing Logs tools below to diagnose the issue.
After triggering a restart or rebuild, the dashboard shows a spinner with a "Restarting..." or "Rebuilding..." label. The status automatically refreshes every 5 seconds until the app reaches a terminal state (running or failed).
Via MCP (AI Agent):
The list-my-apps, get-my-app, and create-my-app MCP tools include a buildStatus field in their output (building, running, failed, or unknown). AI agents can check build status directly:
"What is the build status of my app called myapp?"
"List my apps and show me which ones have failed"
You can attach a Umami web analytics instance to your app to track pageviews and user behavior without cookies. When analytics is configured, you can view your Umami dashboard credentials directly from the My Apps page.
Via the Web Console:
- Go to My Apps
- Click the analytics icon on your application row
- The modal shows your Umami dashboard URL, username, and password (with a show/hide toggle)
Via MCP (AI Agent):
"Show me the analytics credentials for my app called myapp"
When retrieving credentials via an AI agent or MCP tool, the Umami password is returned as a one-time download link rather than in plain text. The link is valid for a limited time and limited number of downloads. Click the link to retrieve the password before it expires.
See the AI-Assisted App Management guide for how to provision and bind an analytics instance using the AI assistant or MCP tools.
When Agentic SDLC is enabled for an app, OSC provisions a private Gitea instance where SDLC tickets and activity are stored. You can retrieve the admin credentials to log into the Gitea web UI directly.
Via the Web Console:
- Go to My Apps
- Click the app row to expand it, then click the app name or the settings icon to open the app detail page
- Click the Git access tab (only visible for apps with a managed Gitea repository)
- The tab shows the git repository URL with a copy button and an Open in Gitea link
- Click Show login credentials to reveal the admin username and password. A confirmation dialog warns that this resets the existing password. Click Continue to proceed.
- Copy and save the displayed credentials immediately. The password is shown only once.
Via MCP (AI Agent):
"Get the Gitea credentials for my app called myapp"
The get-myapp-git-credentials tool returns the Gitea URL, admin username (oscadmin), password, and a direct link to the login page.
To rotate the admin password:
"Rotate the Gitea credentials for my app called myapp"
The rotate-myapp-git-credentials tool generates a new password, updates it in Gitea, and returns the new credentials.
Note: Gitea credentials are only available for apps with a managed Gitea repository (apps not using a GitHub URL as the source). Apps provisioned before the credential-storage feature was introduced may return a "credentials not available" response. Use "Show login credentials" in the web console or the
rotate-myapp-git-credentialsMCP tool once to generate and store a fresh password.
By default, when you deploy an app via My Apps it receives a URL like https://<hash>.apps.osaas.io — a stable but random-looking address. If you want a friendlier URL such as mycoolapp.apps.osaas.io, you can set up a managed domain (subject to availability at no extra cost) or bring your own custom domain (requires a paid plan). See Custom Domains for the full setup guide.
You can add HTTP Basic Auth to any My App that has a custom or managed domain. When enabled, the browser prompts visitors for a username and password before serving your application. This is useful for protecting staging environments, admin panels, or any app you want to restrict to a known set of users.
Basic Auth is enforced at the nginx ingress layer — no changes to your application code are required. It applies to every domain attached to the app, including a second or later custom domain, and to domains added after Basic Auth was enabled. Responses from protected apps are sent with Cache-Control: private, no-store, so shared caches and CDNs do not store them.
curl -X PUT https://deploy.svc.prod.osaas.io/myapps/{appId}/auth \
-H "Authorization: Bearer <your-pat>" \
-H "Content-Type: application/json" \
-d '{"username": "admin", "password": "your-secure-password"}'Constraints:
- Username: 1–64 characters; letters, digits, dots, underscores, and hyphens only
- Password: 12–72 bytes
curl -X DELETE https://deploy.svc.prod.osaas.io/myapps/{appId}/auth \
-H "Authorization: Bearer <your-pat>"The DELETE call is idempotent — it returns 200 even if Basic Auth was not previously enabled.
For a full explanation including MCP usage and notes on certificate provisioning, see Custom Domains: HTTP Basic Auth.
Application logs can be viewed via the MCP tools:
"Show me the logs for my app called myapp"
"Show me the last 50 lines of logs for myapp"
"Show me errors in the logs for myapp since 2026-02-24T10:00:00Z"
The get-my-app-logs MCP tool is the dedicated way to retrieve logs from custom apps deployed via My Apps. You only need the app name — the tool automatically determines the runtime type. You can narrow results with optional filter parameters:
| Parameter | Description | Example |
|---|---|---|
tail |
Return only the last N lines | tail=50 |
since |
Return only logs after this ISO 8601 timestamp | since="2026-02-24T10:00:00Z" |
level |
Filter to a specific log level (error, warn, or info) |
level=error |
If you omit tail, the tool defaults to the most recent 300 lines, with an additional byte-size cap so a handful of very long lines can't overflow the response either. When the output was capped, the response includes a truncated: true advisory — pass an explicit tail or since to retrieve more.
Or via CLI:
npx @osaas/cli logs eyevinn-web-runner myappTo manage environment variables for your application, use a Parameter Store. Values in the parameter store are injected as environment variables when your application starts.
Changes to the parameter store take effect on the next restart or rebuild.
Local disk storage on My Apps is not persistent. Files your app saves itself — uploads, session files, SQLite databases — do not survive a restart, rebuild, or configuration change. To keep data across restarts, connect a managed OSC instance (PostgreSQL, Valkey, or MinIO) via Parameter Store and use it from your app's own code, rather than writing to the local filesystem.
You can add, change, or remove a parameter store binding on an existing app without deleting and recreating it. The app is rolling-restarted automatically to pick up the new configuration.
Via the Web Console:
- Go to My Apps
- Click the Config button on your application row
- Select a parameter store from the dropdown, or choose None to remove the current binding
- Click Save
Via MCP (AI Agent):
"Bind the parameter store called myconfig to my app called myapp"
"Remove the parameter store binding from my app called myapp"
The AI agent uses the update-my-app-config MCP tool, which accepts the app ID and the name of the parameter store to bind (or null to remove the binding).
When deploying a monorepo application using both subPath and configService, be aware that parameter store environment variables are loaded by the Web Runner's root-level startup script. If your workspace defines its own start command (e.g., npm run start --workspace=backend), the workspace script runs directly and may bypass the root-level config loading step.
Symptoms: Your app starts but all parameter store values (DATABASE_URL, SMTP_HOST, etc.) are missing. Logs may show [CONFIG] Loaded 0 environment variable(s).
Solution: Ensure your workspace's entry point handles APP_CONFIG_URL loading. You can do this by adding a start script in your workspace that fetches parameters before starting the app:
// backend/start.js
const { loadConfig } = require('./config-loader');
async function main() {
if (process.env.APP_CONFIG_URL) {
await loadConfig(process.env.APP_CONFIG_URL);
}
// Start your actual application
require('./index.js');
}
main();Or reference the root-level start script if your project structure allows it. The key requirement is that APP_CONFIG_URL must be fetched and its values injected into process.env before your application code runs.
If your app was built from a private repository and the access token expires, builds will fail with a "Source repository is not reachable (404)" error. You can update or remove the token in place; the app is rolling-restarted so there is no downtime and no recreation of the app.
Via the Web Console:
- Go to My Apps
- Click the Config button on your application row
- Scroll to the GitHub Personal Access Token field at the bottom of the Config modal
- Enter your new Personal Access Token (format:
ghp_...) and click Save - A rolling restart is triggered automatically. The app stays available throughout.
Via MCP (AI Agent):
"Update the GitHub token for my app called myapp"
The agent uses the update-my-app-github-token tool. It preserves all existing settings and triggers a rolling restart. The app remains available during the update.
If you already have a GitHub repository you want to host on OSC, you can import it directly rather than starting from scratch. The import flow provisions the app in OSC and sets up a managed Gitea repository for it.
- An OSC account
- A GitHub repository URL (public or private)
- GitHub credentials (Personal Access Token) configured in your OSC profile. If they are not set up yet, OSC will prompt you during the import flow.
- Go to My Apps
- Click the Import button
- Enter your GitHub repository URL in the import dialog
- If GitHub credentials are not configured in your profile, a credential setup prompt appears. Add your Personal Access Token there, then continue.
- OSC provisions the app and sets up a Gitea repository. A progress indicator is shown during this process.
- When the import completes, the app appears in your My Apps list.
- OSC creates a service instance for your app
- A managed Gitea repository is provisioned and linked to the app
- If GitHub credentials were missing, OSC stores them in your Profile settings (Profile > Git credentials) for future use
After importing, the app is provisioned but not yet deployed. Your next steps are:
- Deploy the app — see the Deploy or Publish Your Application guide
- Enable Agentic SDLC — set up automated CI/CD and AI-assisted development via the Agentic SDLC guide
- Add backend services — connect databases, caches, and other services from the OSC catalog
If an app disappears from the My Apps dashboard but you know the app name, use the diagnose-my-app-orphan MCP tool to inspect its state without requiring a registry entry.
The tool inspects the Kubernetes runner namespace directly and returns:
- Registry state — whether the app record still exists in the registry
- Deployment health — whether a K8s deployment is running and the pod count
- Last-known config — the app's source URL, runner type, and parameter store binding (secrets are redacted)
- Parameter store bindings — which config service instance was attached, if any
Via MCP (AI Agent):
"Diagnose my vanished app called myapp"
"My app called myapp disappeared from the dashboard — can you inspect it?"
The tool uses the app name (not an ID) and determines the runner type automatically. If the deployment is still running in K8s but the registry record is gone, the tool surfaces enough information to recreate the app with the same configuration.
HA secondary orphans: If the missing app name ends in b (for example myappb), diagnose-my-app-orphan looks at the primary app (myapp) and reports one of three outcomes.
-
Live HA standby. HA is enabled on the primary. The tool prints the active slot, says whether
myappbis serving traffic, states that it is not an orphan, and suggests no delete. To remove it, disable HA on the primary. -
Orphaned HA secondary. HA is off on the primary, but
myappbis still registered with parameter store bindings. The tool prints what a delete would and would not affect and suggestsdelete-my-app. -
State could not be determined. The tool gives no classification and suggests no delete. Run
get-my-appfor the primary and try again.
Before you delete anything the tool calls an orphan, run get-my-app for the primary and check the HA Mode line and the active slot. If HA is enabled, the instance is part of a working pair and should not be deleted.
When a user asks about managing their app, use this guide. The default action for deploying new code is always restart (without rebuild). Restart uses the build cache and is significantly faster. Only use rebuild when caches are explicitly the problem.
| User wants to... | Recommended action | Use rebuild? |
|---|---|---|
| Deploy latest code changes | Restart | No |
| Update after pushing new commits | Restart | No |
| Fix a bug by pushing a code fix | Restart | No |
| Fix dependency or cache issues | Rebuild | Yes |
| Pick up new base image / runtime | Rebuild | Yes |
| Restart did not fix the issue | Rebuild (as last resort) | Yes |
| Keep serving the old version during a restart or rebuild | Enable HA (requires paid plan), then restart | No |
| Use a custom domain | See Custom Domains guide | N/A |
| Password-protect my app with Basic Auth | Use PUT /myapps/{appId}/auth API or see HTTP Basic Auth section |
N/A |
| Deploy from a specific branch, tag, or commit SHA | Pin to the ref via Settings tab | No |
| Change environment variables | Update parameter store, then restart | No |
| Add, change, or remove parameter store binding | Use Config button (web) or update-my-app-config (MCP) |
No |
| Check if app built/deployed successfully | Check build status in My Apps dashboard or ask AI agent | N/A |
| App shows "Build failed" | Check logs, fix the issue, push fix, then restart | No |
| Node.js/TypeScript build fails with "No package.json found" | Your repository must have a package.json at the root — OSC now surfaces this as a clear error (missing_package_json) rather than a cryptic ENOENT
|
N/A |
| App creation fails with "Repository not found" | The URL may be wrong or the repository is private — add a GitHub Personal Access Token in the Git Token field during creation, or save credentials in your account settings first | N/A |
| App fails with "Source repository is not reachable (404)" | Update GitHub token via Config button → GitHub Personal Access Token field (web) or ask AI agent | N/A |
| App disappeared from the My Apps dashboard | Ask AI agent (diagnose-my-app-orphan) to inspect K8s state and retrieve last-known config |
N/A |
| Set up web analytics | Ask AI agent or see AI-Assisted App Management | N/A |
| View Umami analytics credentials | Click analytics icon in My Apps (web) or ask AI agent | N/A |
| Access Gitea web UI for SDLC tickets | Ask AI agent (get-myapp-git-credentials) or see Accessing Gitea Credentials
|
N/A |
| Rotate Gitea admin password | Ask AI agent (rotate-myapp-git-credentials) |
N/A |
| Invite a collaborator to the Gitea repo | Open app detail → Collaborators tab → Invite collaborator | N/A |
| Revoke collaborator access | Open app detail → Collaborators tab → Revoke | N/A |
Important for AI agents: When using the restart-my-app MCP tool, do NOT set rebuild=true unless the user specifically asks for a rebuild or the situation matches one of the "Yes" cases above. Omitting the rebuild parameter (or setting it to false) triggers a fast restart that reuses the build cache.
- AI-Assisted App Management — Deploy, configure, and troubleshoot apps using natural language
- Deploy or Publish Your Application — How to deploy apps on OSC
- Custom Domains — Setting up custom domain names
- Parameter Store — Managing application configuration
- Service: Web Runner — Web Runner (Node.js) service documentation
- Service: Python Runner — Python Runner service documentation