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.

1Fill in the starter prompt below and give it to Claude.
2Put the result in a repo in the DGR-Media GitHub org.
3Admin → DGR Apps → New app → Create.

Before you start (once only)

1. Build it with Claude

What works well here

DGR Apps is built for small, public, mostly-read sites. Some starting points, each with the kind of thing to type into the brief below:

Campaign landing page

One page, one message, one button.

A landing page for our spring promo with a hero, three benefits and a "Play now" button to scratchee.com.
Event or launch page

Countdown, schedule, map, FAQ.

A page for the Brisbane launch night with a countdown to 14 Nov 7pm, the running order and a map.
Client pitch or proposal

A polished page instead of a PDF. Add noindex.

A one-page pitch for Acme with our approach, three case studies and pricing tiers.
Calculator or estimator

Runs entirely in the browser, nothing stored.

An ROI calculator: inputs for budget and conversion rate, shows projected return with a chart.
Quiz or "which one are you?"

Answers scored in the browser, result shown at the end.

A 6-question "what kind of player are you" quiz with four result types and share buttons.
Link hub or microsite

Link-in-bio, partner page, resource list.

A link-in-bio page in our brand colours with our socials and the latest three promos.
Internal reference page

Style guide, how-to, FAQ — like this manual.

A brand guide page showing our colours, fonts, logo do's and don'ts.
Interactive prototype

Show a client or the team how something would feel.

A clickable mock-up of a new rewards screen, fake data, works on a phone.
Good fit
  • Pages that look the same for everyone
  • Anything that runs in the browser
  • Forms that send to a service you already use (HubSpot form, Google Form, email service)
Not a fit
  • Storing data — there is no database, and files saved on the server vanish on every deploy or restart
  • Logins or anything private — every site is public
  • Taking payments or handling player data
  • Heavy apps — the space is small and shared

Not sure if your idea fits? Ask Claude: paste the prompt below and add "before building anything, tell me if this will work on DGR Apps".

The starter prompt

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 as the first message of your project, with the square brackets filled in. The top half tells Claude what you want; the bottom half makes it build the right shape from the beginning. Fixing it afterwards is slower than starting right.

Paste this into Claude first 
I want to build: [one sentence — e.g. a landing page for our spring promo]

Who it's for: [customers / a client / the team]
What they should do on it: [e.g. click through to scratchee.com, fill in a form, read the FAQ]
Sections or pages: [e.g. hero, how it works, prizes, FAQ, footer]
Look and feel: [brand colours, fonts, a site you like the look of — attach logo and images if you have them]
Words: [paste the copy, or "write placeholder copy I can edit"]
Forms: [none / send to (HubSpot form, Google Form, email service)]
Draft or public: [draft — keep it out of Google / public]

Ask me anything you need before starting. Keep it simple: plain HTML, CSS and
JavaScript unless it genuinely needs a framework. Make it work well on a phone.

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.
- There is no database and the server's disk is wiped on every deploy. Don't
  save anything to files on the server; if something must be stored, tell me
  and suggest an outside service instead.
- Keep it light: the server is small and shared with other sites.
- Add a .gitignore that leaves out node_modules, dist and .env.
- Save these rules to a CLAUDE.md file in the project so you follow them
  every time I come back to it.
- When it's done, tell me how to preview it on my computer.

While you build

2. Put it on GitHub

The repo has to live in the DGR-Media organisation. Private is fine and is the sensible default — it makes no difference to publishing, and the site itself is public either way once deployed.

Naming: lowercase words joined by dashes, like spring-promo-2026. The deploy page suggests the web address from the repo name, so a good repo name saves a step.

Route A — let Claude do it

For the Claude desktop app's Code tab. Nothing to install yourself.

When the site is ready, send Claude:

Put it on GitHub 
Put this project on GitHub as a new private repo called [spring-promo-2026]
in the DGR-Media organisation, and push everything. If GitHub isn't set up on
this computer yet, walk me through signing in step by step. Check that no
passwords, keys or .env files are included before pushing. When you're done,
give me the repo link.

The first time, Claude may ask to install the GitHub command-line tool and open a browser window for you to sign in. Say yes and follow it — after that it just works.

To ship a change later: ask for the change, then say "commit and push". Then press Deploy.

Route B — the GitHub website

For projects built in Claude chat, or when you'd rather click than type. Best for plain HTML sites.

  1. Create the repoGo to github.com/new. Set Owner to DGR-Media (not your own name), type the repo name, choose Private, leave everything else alone and press Create repository.
  2. Upload the filesOn the empty repo page, click uploading an existing file. Open your project folder, select everything inside it and drag it onto the page. index.html must end up at the top level, not inside a folder.
  3. Leave these outnode_modules, dist, .env and anything with a password in it. GitHub takes 100 files per upload — if you hit that, you have probably included node_modules.
  4. SaveScroll down and press Commit changes.

To ship a change later: in the repo, Add file → Upload files and drop in the changed files — same name replaces the old one. Commit, then press Deploy.

Owner dropdown doesn't show DGR-Media? You are not in the organisation yet — send Ramy your GitHub username, or check your email for an invite you haven't accepted.

Repo isn't in the deploy page's list? Refresh the New app page first. Still missing? Send Ramy the repo name — the deployer is given access to repos one at a time, so the Scratchee platform code can never be published by accident.

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.

Quick check before you deploy

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