SkillCDN 콘솔

Deploying a console for an organization

What goes in: an AWS account, a domain on Cloudflare or one to buy, and the answers to a few plain questions. What comes out: the console at https://<hostname>, signed in by its first administrator, with a first project and an agent connected; running as containers on AWS next to a managed PostgreSQL and a bucket, reached only through Cloudflare, every secret in a parameter store; a private deployment repository whose every push rebuilds and redeploys; a budget alert; and a record, DEPLOY.md, of what exists and how it is run. The person never needs to know the cloud: every choice is derived from their answers, shown with its cost, and changed when they ask. The shape and why it was chosen are ADR-0017; what the console asks of any platform is deploy/README.md.

How the person is involved

• Questions: one message at the start, the ones under "Inputs" that the request leaves open, in plain words. Then a second message, so that the questions stay short: the order of cost for the size (sizing.md's snapshot, named as such) and the two credentials to create (access.md), so that the person knows what it costs before an account or a key exists, and the credentials are ready when the plan is.
• Checkpoints: the plan with today's cost, before anything is made; each purchase with its price (a domain); a secret only the person holds, asked with the exact steps once the address is known; the first push, which starts the first build and makes the address public once it serves; the record's push; the deletion of the secrets file and the token file. One short message each, with the recommendation, and "OK", in the person's language, continues.
• Go-ahead: when the person says to go ahead alone, the reports between phases need no answer. The plan, a purchase, the first push and a deletion are confirmed in every mode.
• Waiting: what only the person or the world can finish, the run waits for, in the open. A domain whose nameservers the person must change answers at Cloudflare minutes to hours later: the zone is made first, the steps go out in the second message, and from phase 5 the run checks the zone every ten minutes for up to an hour, saying so; still not there, it stops with the record saying what waits and resumes at phase 5 when the person says the nameservers are set. The only way of signing in answered later means nobody can sign in: the run stops at phase 5 the same way and resumes when the secret is in the secrets file.
• Changes mid-run: applied from that point. What was created is kept and recorded, never silently deleted.
• Language: messages to the person in the language they wrote in; the repository's files in English, its README.md and DEPLOY.md in the organization's language.

Requirements

Check these before the first message. Without the AWS CLI, offer to install it (access.md); without gh, the person makes the repository; without network, stop. This skill's own pages (access.md, sizing.md, resources.md) arrive with it through SkillCDN, in the package, and in a copy of its directory. deploy/README.md and the decisions are read through the repository connection or in a checkout of the console's repository; without them, this skill and its pages carry the shape.

Inputs

Workflow

Each phase produces a named artifact and ends with one line to the person. The procedure of each, its commands, its checks and what to do when a step fails, is in resources.md under the phase's name; the sizes and the prices in sizing.md; the credentials and the dashboard steps in access.md.

Phase 1: Access

Produces the access record: the account id, the region, the default VPC and its subnets, the Cloudflare account and the zone of the domain (or none yet; or one that serves the organization's site already), the git host owner. Make the run's folder with its scratch/ subfolder and .gitignore; install the console command and copy this skill's scripts into scratch/; import the key into the profile console and read the token from its file, as access.md says, and verify each with the harmless calls there. What a harmless call can show, report now with the row to add: an action the deployer's policy lacks. A Cloudflare token's permissions show only at the first creation, since Read lists what Edit makes, so the step that fails names the row (resources.md "When a step fails").

Phase 2: Plan and estimate

Produces the plan, shown at the checkpoint. From the answers: the size and what it is made of (sizing.md "The sizes"); today's prices, read as sizing.md "Reading today's prices" says, and the estimate of this size and the next one, each line saying whether it is today's price or the snapshot; the resources to create under which names; the domain's path (owned, with the registrar's steps already sent; bought at the price shown); the secrets, which are generated, which are derived, and which the person holds and will be asked for at phase 3 with the exact steps; the budget alert; the few steps only the person takes, and when. Then stop, with the estimate message of sizing.md and: "I will create <the resources>, set <n> secrets, connect <hostname> through Cloudflare, and make a repository at <owner>/<name> that deploys on every push. You do once: <the steps>. OK?"

Phase 3: Foundation

Produces the resource record: each resource with its name and id. In this order: the zone at Cloudflare, with the records the domain serves already found by Cloudflare's scan and checked by the person against their registrar's DNS page, so that nameservers propagate meanwhile; the network and its two security groups; the database, started, and waited for while the rest is made; the bucket; the image repository, the log group, the roles, the task's with the bucket's policy, the cluster; the tunnel, the hostname, always-HTTPS for the hostname and the rate limiting rule; the parameters, generated and derived, from the secrets file. Then, the hostname being known, the message for each secret the person holds (access.md "The OAuth app", "The OAuth client"): "Save it in the secrets file as the line I show, or say later and that way of signing in stays off until it is set." A value the person pastes into the chat instead is written into the file by the agent's file tool, never repeated, and the person is told to generate a new one once the run is over, since the chat kept a copy; the new one goes in as "a secret rotated" of the record.

Phase 4: The deployment repository

Produces the repository: deploy/console.env, the task definitions deploy/migrate.task.json, deploy/api.task.json and, at the large size, deploy/worker.task.json, the workflow .github/workflows/deploy.yml, README.md and a draft DEPLOY.md, as resources.md gives them, every value filled from the record; and on AWS the role the workflow assumes, trusted for this repository's main alone. Show the files, each with the lines that matter pointed out for a person who is not a developer; commit; create the empty private repository. Checkpoint: "Pushing starts the first build (about ten minutes), runs the migrations, and starts the console at <hostname>. OK?" On the word, push, and watch the run to its end.

Phase 5: Live

Produces the live address. The zone is active (else the wait of "How the person is involved"); https://<hostname>/readyz answers 200 through Cloudflare; the page shows the sign-in buttons of the providers set (none set: the stop of "How the person is involved"); the tunnel shows a connector; the log says api listening and files go to the bucket; the rollout is complete. Create the budget alert. Report the address.

Phase 6: The first people

Produces the first administrator and the first project. Tell the person: "Open <address> and