Apps

Add a Postgres database to an EXISTING Node app that doesn't have one, one DB per environment, with DATABASE_URL injected into each app environment (restart/redeploy to pick it up). The password is set server-side and never returned. Support Plus+; static apps and apps that already have a DB are refused. Use the awesomate-database skill's decision tree first, a simple list an automation reads/writes is often better as an n8n data table.

Call FIRST before any app-builder work. Returns the connected account's plan, whether the app builder is unlocked (capability.appBuilder, Support Plus+), whether they have a cPanel hosting account yet, their existing apps, firstRun, and capability-aware next-step suggestions to offer the user. If appBuilder is false, relay the upgrade suggestion rather than attempting to build.

List the client’s apps (id, slug, kind, status, primary_domain, github repo). Use to find an appId before get/deploy.

Get one app plus its environments (subdomains, ports, db engine/name, deploy + health state) and any hostnames of the user's own attached to them. Poll this after awesomate_app_create: status goes provisioning → active | failed (read provision_error on failure; to retry, call awesomate_app_create again with the same appSlug, or remove it with awesomate_app_remove_failed). With domains:true it returns only the app's own hostnames, each with its DNS record to set and where HTTPS stands, read fresh.

Remove an app whose setup FAILED (awesomate_app_get shows status 'failed'), clearing whatever the attempt left on the user's hosting (subdomains, databases, folders). Only failed apps: an active, provisioning or suspended app is refused with 409 not_failed, and removing a working app stays a support request. A failed app already holds no plan slot and does not reserve its name, so to RETRY just call awesomate_app_create again with the same appSlug: the hub clears the failed attempt first. Use this when the user wants the failed app gone, not to retry. Tell the user what will be removed and get a yes first; confirm must equal the app's slug.

Provision a new app on the client's cPanel account. Choose the stack deliberately (see the awesomate-app-builder skill): kind 'static' = a single fast landing/lead page served straight from the docroot (no DB, no server process, pick this for brochure/landing/lead-capture); kind 'node' = a dynamic app with a backend + database (logins, custom logic, an API). Pick the template by job, 'node-auth-sync' (user accounts/logins, MySQL), 'node-crud-postgres' (structured data without logins: trackers/dashboards, ready-made CRUD + UI, Postgres), 'node-api-only' (webhooks/integrations/glue, no DB wiring), 'static-landing' (marketing/lead page). If dbEngine is omitted the template's native engine is used (node-crud-postgres → postgres). Returns 202 immediately with an appId + subdomain(s); poll awesomate_app_get until status=active, then fetch the starter files with awesomate_app_scaffold. Requires apps:write (Support Plus+), a 403 means offer an upgrade. Plans also cap the NUMBER of apps (Support Plus 5, Pro 20, check awesomate_get_limits.dimensions.apps first): a 409 with code 'app_limit' means the cap is reached, do NOT retry; tell the user their allowance is full and surface the recommendedPlan/deepLink from the error. Get the user's confirmation on the stack + name before calling.

Fetch the app's starter files (its template rendered against the live app metadata, subdomains, control-plane URL, repo, with placeholders already substituted). Call after awesomate_app_create reaches status=active: write each returned file into a fresh local project folder at its relative path, then run npm install (Node apps) and follow the bundled CLAUDE.md. This is how the starter code gets onto the user's machine, don't reconstruct templates by hand. mode 'adopt' is for a repo that ALREADY exists (Replit, Lovable, anything): it returns only the plumbing (.github/workflows/deploy.yml, .awesomate.json with the deploy contract, scripts/security-check.mjs, scripts/awesomate-migrate.mjs, AWESOMATE.md) to write into that repo without touching its code. Run awesomate_app_repo_check first so the deploy block is pre-filled from the check.

READ-ONLY deploy briefing, this never deploys anything (deploys happen via git push). Reports how to deploy an app, its per-env targets, last-deploy/health state, whether a deploy key is registered, and how to promote (dev→staging→main) or roll back (git revert + push). Node apps deploy via git push (dev/staging/main → GitHub Actions builds on its runner → artefacts shipped to cPanel; nothing builds on the account). First-time wiring is awesomate-github/scripts/deploy-key.mjs <appId>, no ticket needed. For an existing repo being moved from Replit or Lovable, start with awesomate_app_migration_plan.

Link an app to the GitHub repo it deploys from and record where the code came from. Call it as soon as the repo is known (owner/repo) for an app being moved from Replit, Lovable or any existing codebase; deploy-key.mjs also calls it for you when it sets the repo secrets. autoTickets:false turns off the hub's automatic support tickets for this app (they are on by default and open a Desk ticket when a rule fires: a committed secret, a blocker reported three times, a deploy failing three times in a day).

Report the JSON produced by node ~/.claude/skills/awesomate-app-builder/scripts/migrate-check.mjs [--fix] for the repo this app deploys from. The hub stores it, updates the migration plan (repo_checked becomes done when no blockers remain), pre-fills the deploy block that awesomate_app_scaffold mode 'adopt' returns, and applies its ticket rules: a committed secret opens a Desk ticket at once; the same blocker reported three times opens one; otherwise nothing is sent. Fix blockers in the code, re-run the script, report again. Never paste source code into this call; the report carries rule ids, file paths and one-line details only.

Record the outcome of a deploy to one environment, after gh run watch finishes or the manual artefact deploy exits. Pass outcome 'failure' with the failing step name (from gh run view --log-failed) or 'success' with the commit sha. The hub updates the plan and, after three failures on one env inside a day, opens a support ticket itself and tells you so; do not push again blindly and do not raise the ticket yourself.

The hub-computed checklist for getting an existing app (Replit, Lovable, any repo) running on Awesomate: ordered steps, each done / todo / blocked / not_applicable / unavailable, with the exact tool or script that completes it, and any support ticket the hub has already opened about it. Call it at the start of a migration session and after each step; follow next. The capacity step reads the account's real limits (awesomate_app_capacity) and the hostname step attaches the user's own subdomain (awesomate_app_domain_attach).

THE answer to 'will this app fit on my hosting' or 'is my hosting big enough for it'. The limits are the account's, so for an app not created yet pass any existing app's id. Reads the account's live limits and last-day peaks (memory ceiling shared by every environment and the website, task limit where a Node process costs about 11, disk, database sizes, any install or build running on the account, pm2 restart loops) and returns a verdict: ok, warn, blocked or unknown, with reasons and headroom. Call it before the first deploy and again before prod. With fix:true it raises the account's task and memory limits to the platform floors (raise-only, never lowers) when that is what blocks; anything left after that is for Awesomate and the hub opens a support ticket itself and shows it here; do not raise one yourself. Runs a few seconds of server reads; do not poll it.

Put the user's own hostname on an app environment (default prod), so the switch from their old platform is a DNS change. The hostname must be a SUBDOMAIN of a domain already on their hosting account (app.theirdomain.com); the apex and www stay with whatever serves them today, usually their website. Creates the cPanel subdomain and the reverse proxy for that environment, and returns the exact DNS record to set, whether it already points at Awesomate, and a certificate block saying where HTTPS stands. The hub probes the hostname every minute and issues the certificate within about two minutes of the record landing, so tell the user to expect the padlock shortly after DNS, never "within the hour"; ssl carries the sentence to relay. Calling it again for a hostname already attached is a cheap DNS re-check (no reconfiguration, no Apache reload); pass reattach:true only to rewrite the plumbing. awesomate_app_get also re-checks DNS for attached hostnames. Node apps only; a domain not yet on the account needs awesomate_domain_add first. A 503 hostname_attach_disabled means Awesomate has not switched this on yet: tell the user, keep prod on its Awesomate address, do not retry.

Store an API key / secret for a Node app environment: it's encrypted in the hub AND injected into the app's .env (0600) then the app restarts. ALWAYS use this instead of putting a secret in code, a committed file, or leaving it in the chat. NEVER echo the value back, confirm with the key name only. Node apps only (static sites have no server env). A key for the user's n8n automations never goes here: it belongs in a credential on their n8n (awesomate-n8n skill). If the user pastes an APP's key in chat, store it here and tell them (per the awesomate-credentials skill) it should be rotated since it passed through the transcript.

Probe an app's environments live and report health. Node envs hit /api/ready (200 = deployed + DB up + migrations applied); static hits the root. An env that isn't deployed yet reports unreachable, expected, not a failure. Use after a deploy to confirm it came up, or when the user says something's down.

Start or stop ONE environment of a Node app (its pm2 process). Use stopped to turn off a dev or staging environment the user has finished with. This frees process capacity on their hosting account, which is a real constraint: the account has a fixed number of processes it can run at once, and idle environments can starve the account's own websites. Use running to bring one back before you build or test on it. Stopping deletes NOTHING: code, database and address all stay, and starting again takes seconds. PRODUCTION CANNOT BE STOPPED (400 prod_not_stoppable); it is the address the user's customers reach. A 409 run_state_failed on a start means the account has no spare capacity, and the response carries nprocUsed/nprocLimit; tell the user which environment to stop rather than retrying. Static sites have no process (400 static_app). Requires apps:write (Support Plus+). Good habit: start dev before a build session, stop it after.