DGR Apps

Publish a site without asking anyone

Build it with Claude, put it on GitHub, press Deploy. A few minutes later it is live on its own address with a padlock — no tickets, no waiting.

1Ask Claude to build it, using the prompt below.
2Push it to a repo in the DGR-Media GitHub org.
3Admin → DGR Apps → New app → Create.

1. Build it with Claude

Claude will happily build something that cannot be published — an app that listens on the wrong port, or one with the password baked into the code. Paste this at the start of your project so it builds the right shape from the beginning. Fixing it afterwards is slower than starting right.

Paste this into Claude first 
This project will be published on DGR Apps (Linux container, public address on dgr-apps.com).

Please build it so it deploys without changes:
- A static site, a Node app, or anything at all if you include a Dockerfile.
- If it is a Node server: listen on process.env.PORT (it will be 8080), and
  include a "start" script in package.json.
- If it is a built front end (Vite, React, Vue, Astro): include a "build"
  script that outputs to dist/.
- Commit the lockfile (package-lock.json, pnpm-lock.yaml or yarn.lock).
- Never put passwords, API keys or tokens in the code or in a committed file.
  Read them from environment variables and tell me which ones you used — I will
  add the values on the deploy page.
- If this is a draft nobody should find on Google, put
  <meta name="robots" content="noindex"> in the page head.

If you are keeping the project around, ask Claude to drop the same text into a CLAUDE.md file in the repo. It will then follow the rules every time you come back to it, including months later.

2. Put it on GitHub

The repo has to live in the DGR-Media organisation. New repos show up in the deploy page immediately — nobody has to grant access first.

Private is fine. Public is fine. It makes no difference to publishing, and the site itself is public either way once deployed.

The one thing that will stop you. If the repo contains something that looks like a password or a key — a .env file, a certificate, a connection string with a password in it — the deploy is refused and nothing is published. That is deliberate. Take the secret out of the repo, and add it as an environment variable on the deploy page instead.

3. Deploy it

In Admin, open DGR Apps in the sidebar, then New app. Five fields, three of which you can usually ignore.

FieldWhat to put
RepositoryPick yours from the list. Newest first.
BranchFills in automatically with the repo's default. Change it if you are publishing from somewhere else.
AddressThe part before .dgr-apps.com. Suggested from the repo name — lowercase letters, numbers and dashes. You see the full address as you type.
App folderLeave empty unless the app sits in a subfolder of the repo.
Environment variablesOne NAME=value per line. This is where keys and passwords go. Values are stored and applied to the app, and never shown again on the page.

Press Create and deploy and you land on the app's page, which updates itself while it works.

What happens after you press it

  1. Fetchinga few seconds Downloads the latest commit on your branch and checks it for anything that looks like a password.
  2. Detectinginstant Works out how to run it. Your Dockerfile wins if you wrote one; otherwise it recognises Next.js, a Node server, a built front end, or a plain HTML site. The page tells you which it picked.
  3. Building30 seconds to a few minutes Builds the container in Azure. If this fails, nothing changes and the previous version keeps serving.
  4. Deployingunder a minute Starts the new version.
  5. Securingthe slow one — first deploy only Sets up the address and the HTTPS certificate. This is the longest step and it only happens once per app. Later deploys skip it.
  6. Verifyingup to five minutes Loads the address to check it actually answers. If it does not, the previous version is put back automatically and the site stays up.

Day to day

Each app has three buttons.

Deploys are not instant-swap: there are a few seconds where the app restarts. Fine for a marketing site, worth knowing if you are demoing live.

When something goes wrong

Failures are shown in plain language on the app's page, and every attempt keeps its full build log — click log next to any row in the history.

Couldn't tell how to run this repo. Ask Claude to add a Dockerfile that listens on port 8080.

Nothing recognisable was found — no index.html, no package.json with a usable script, no Dockerfile.

Fix: exactly what it says. Ask Claude for a Dockerfile that listens on port 8080, push, press Deploy.

This repo looks like it contains credentials, so it was not published.

A key, certificate or password was found in the repo. The message names the files.

Fix: remove them from the repo, read them from environment variables instead, and add the values in the app's settings. If it was only ever an example file, rename it to something like .env.example.

The build failed.

Your app did not compile. This is the ordinary kind of broken.

Fix: open the build log, give the error to Claude, push the fix, press Deploy. Your live site was never touched.

The new version didn't respond, so the previous one was put back.

It built and started, but never answered. Almost always the wrong port.

Fix: make sure the app listens on process.env.PORT. The site stayed up on the old version throughout.

The plan is full.

There is a limit on how many apps run at once. Delete one you have finished with, or ask Ramy to make the plan bigger.

Two statuses worth recognising

Live (no HTTPS) means the site is working, but the certificate has not come through yet. It is reachable — just not with a padlock. Press Deploy again a few minutes later and it usually sorts itself out.

Failed on an app that has never worked means the first deploy never succeeded. The address and certificate are kept so a retry is quick. On an app that has worked, the old version is still serving and visitors saw nothing.

Things that are easy to forget