Awesomate docs v0.93.0

Guides

Apps

Build an app on your Awesomate hosting, or bring one from Replit, Lovable or any GitHub repo, with dev, staging and live copies, a database, secrets kept out of the code, and your own address. Support Plus and above.

Apps are Support Plus and above. awesomate_app_context tells Claude what your account can do before it starts.

Build a new one

Build me a booking page for my studio, with a form that emails me each request.

The awesomate-app-builder skill picks the simplest thing that works: a single fast page for a landing or lead form, or a Node app with a database when you need logins or your own data. Claude creates it (awesomate_app_create), writes the starter files (awesomate_app_scaffold), and deploys by pushing to GitHub.

Each app has its own copies: dev and staging to try things, and live for your customers. A change goes to dev first, then staging, then live.

Bring one you already have

I built an app in Replit. Can you move it onto my Awesomate hosting?

awesomate_app_migration_plan gives a step-by-step checklist for your app, marking each step done, to do or blocked. Claude checks the code for what would stop it running here (awesomate_app_repo_check) and fixes what it can, links the app to its GitHub repo (awesomate_app_update), and sets up deploys. If something needs our team, the hub opens the support ticket itself.

Running it

  • Secrets (API keys, passwords) go in with awesomate_app_set_env: encrypted, put into the app's settings and never into the code or the chat.
  • A database. awesomate_app_provision_db adds Postgres to a Node app, one database per copy.
  • Your own address. awesomate_app_domain_attach puts a subdomain of one of your domains (such as bookings.yourbusiness.com.au) on the app and tells you the DNS record to add. HTTPS follows within a couple of minutes of the record working. If attaching addresses isn't on your account yet, Claude tells you.
  • Deploys. A deploy is a push to GitHub; Claude never deploys any other way. awesomate_app_deploy_info explains how this app deploys, where each copy goes and how to roll back, and awesomate_app_deploy_event records how each deploy went. After three failed deploys of one copy in a day, the hub opens a support ticket itself and Claude tells you.
  • Health. awesomate_app_health checks each copy is answering, awesomate_app_get shows its state (or, with domains, just your own addresses on it with their DNS and HTTPS), and awesomate_app_list lists all your apps.
  • A setup that failed. If an app's setup fails, it doesn't use one of your plan's app slots or keep its name: ask Claude to build it again with the same name and the hub clears the failed attempt first. To drop it instead, awesomate_app_remove_failed removes it and whatever it left on your hosting. Only a failed app can be removed this way; removing a working app is a request to support.
  • Room on your plan. Apps share your hosting's memory and processes with your website. awesomate_app_capacity checks an app will fit, and awesomate_app_run_state switches off a dev or staging copy you've finished with, to free room.
  • Your automations as the back end. awesomate_n8n_attach_to_app lets an app call a workflow in your n8n, instead of you writing server code.

Every tool is in Apps. For an app whose customers sign in and see their own records, see Contacts and portals.