Putting your build online
Your crate is a finished product. This is how it gets an address on the internet — every screen, in order, assuming you have never done any of this before. Budget about 45 minutes the first time. Everything here is free to start; the only card you enter is on a hosting account that belongs to you.
Three words you will see everywhere. A repository (or "repo") is a folder of your product's files with its full history, kept on GitHub. A host is a company whose computers run your product and hand it to visitors. A deploy is the moment a host takes your files and puts them live. That is all the vocabulary you need.
By the end: a GitHub account that owns a copy of your build, a hosting account in your name, and a public address like your-product.netlify.app or your-product.up.railway.app that anyone can open. Later, when you want changes, a new build pushed to the same repository goes live on its own.
Every delivered build carries two plain-English files. HOSTING.md says what kind of host this particular product needs and, if you chose git delivery, may carry a one-click deploy button. RUNNING.md appears only when your product has a server or a database and says what it needs to run. Open them in any text editor — or straight on GitHub once step 1 is done — and keep them beside this guide.
GitHub: an account, then an empty repository. GitHub is where your build's files live and where the Foundry delivers them. It is free for this. Do this part before you accept your quote if you can, so the build lands in your repository the moment it is stamped — but it also works afterwards.
Go to github.com/signup. Enter your email, choose a password, pick a username (it becomes part of your repository's address, so something you would put on a business card). GitHub emails you a code; type it in. When it asks about plans, the Free plan is the right one. Skip any survey.
Signed in, go to github.com/new. Give it a short name with no spaces (choir-scheduler, not Choir Scheduler v2). Choose Private unless you want the world to read the code. Leave every checkbox off — no README, no .gitignore, no license: the repository has to be completely empty, because the Foundry brings the whole history with it. Press Create repository. You will land on a page full of instructions for developers; ignore all of it.
Back on your Melodic Foundry order page, the GitHub delivery card has a Connect GitHub button. It takes you to GitHub, which asks where to install "Melodic Foundry Delivery". Choose Only select repositories and pick the one you just made — nothing else. Press Install. GitHub sends you back to your order, which now shows the repository as connected. That permission is yours: you can remove it any time in GitHub under Settings → Applications, and after delivery there is no reason to keep it.
When you stamp the finished build, the Foundry pushes every file and every commit into that repository. Open github.com/<your-username>/<repo-name> and you will see the code, a README, and the two files from "Before you start". If you connected the repository after delivery, the counter pushes it to catch up.
Which host do you need? Open HOSTING.md in your repository. Its first section names the kind of host in one line, and that line decides which of the next two steps is yours:
If it says a static-file host (a single-page app, a site with no server), go to Step 3, Netlify. Free for a site like this. Cloudflare Pages is an equally good host of the same kind — the steps rhyme.
If it mentions a server, Node, PHP, or a database (MySQL or Postgres), go to Step 4, Railway. Railway runs the product and the database side by side and starts with a small free credit; after that it bills for what the product actually uses, which for a small product is a few dollars a month.
If your repository contains a file called compose.yaml or RUNNING.md, it has a server: Step 4. If it does not, Step 3. If HOSTING.md has a Deploy to Netlify button, that button is Step 3 done in one click — press it and skip to 3d.
Netlify, for a website. Netlify watches your GitHub repository and rebuilds the site whenever it changes. Free for a personal or small-business site.
Go to app.netlify.com/signup and choose Sign up with GitHub. Using GitHub to sign in saves a step later and means one less password. GitHub asks you to authorize Netlify; say yes. Netlify may ask a few questions about what you do; answer or skip.
On your Netlify dashboard press Add new site (or Add new project) → Import an existing project → GitHub. The first time, GitHub asks which repositories Netlify may see; choose Only select repositories and pick yours. Then click the repository in Netlify's list.
Netlify reads the repository and fills in the build settings itself — usually a build command like npm run build and a publish folder like dist. Check them against the "Build" lines in HOSTING.md; if they match, leave them. Press Deploy. A log scrolls for a minute or two and ends in Published.
Netlify gives the site a random name like amber-otter-1a2b3c.netlify.app. Open it — that is your product, live. To change the name: Site configuration → General → Site details → Change site name. Your own domain is Step 6.
Every push to the repository redeploys the site automatically. A change round from the Foundry lands in the same repository, so it goes live on its own when you stamp it. If a deploy ever fails, the log Netlify shows names the line that failed — that is the text to paste into your order's thread.
Railway, for anything with a server. Railway runs your product's server, and its database if it has one, from the same repository. It starts with a free trial credit and then bills for actual use; a card is required to keep a project running past the trial, which is also what lets a launched project be handed to you.
Go to railway.com and press Login → Login with GitHub. Authorize it. Then, in Account settings → Billing (or the Upgrade button), choose the Hobby plan and add a card. The plan's monthly fee includes usage credit; a small product rarely exceeds it. Without a card, a project stops when the trial credit runs out and a transfer to you cannot complete.
Press New Project → Deploy from GitHub repo. The first time, Railway asks GitHub which repositories it may see; choose your repository only. Pick it. Railway creates a project holding one service (your product) and starts building it. It works out how to build from the files in the repository; RUNNING.md says what it should find.
Only if RUNNING.md names one. In the project view press Create (the + button) → Database → MySQL or Postgres, whichever the file says. Railway starts it beside your service in the same project.
Click your product's service → Variables. Open .env.example in your repository: each line there is a setting the product expects. Add each as a variable. For the database ones, use Railway's Add Reference (or type ${{MySQL.MYSQL_URL}} / ${{Postgres.DATABASE_URL}}, matching the database you created) so the connection details come from the database service itself and you never copy a password by hand. Press Deploy when Railway offers to apply the changes.
Still in the service: Settings → Networking → Generate Domain. Railway gives you an address like choir-scheduler-production.up.railway.app. Open it. If it shows your product, you are live. If it shows an error, the Deployments tab has the log; the last red lines are what to paste into your order's thread.
Every push to the repository redeploys the service. The database keeps its data across deploys. Railway's Usage page shows what the month has cost so far; for a small product that number is usually a few dollars.
If we launched it for you. The Launch it for me add-on means your operator did Step 3 or Step 4 on a hosting account we hold, checked the product works at its address, and now hands the whole hosting project to an account in your name. After the handover the host bills you, every setting is yours, and nobody else holds the keys. Here is what it looks like from your side.
Do Step 1a if you have not (your repository is already yours — the operator deployed from it). Then create the hosting account: 3a for Netlify or 4a for Railway, whichever your operator named in the thread on your order page. Add a card before the handover — on Railway a project cannot move to an account without one, and on any host a project with no card behind it can stop.
Reply in the thread with the email address your hosting account uses. Your operator sends the transfer to that address. On Railway it arrives as an email and as a notification in your dashboard: open it and press Accept; the project appears in your account. On Netlify the operator transfers the site to your team; you will see it on your dashboard, and Netlify may ask you to confirm. Tell the thread when you see it.
The transfer moves the running project but not the link between the host and your repository, because that link used the operator's GitHub permission. Re-make it as yourself: on Railway, service → Settings → Source → connect your repository; on Netlify, Site configuration → Build & deploy → Link repository. From then on a push redeploys, exactly as if you had set it up yourself.
Any password or key the operator entered while launching — the database password, an email-service key — is replaced with a fresh one at handover, so nothing they saw still works. Your operator does this and tells the thread. If the product needs a key only you can make (a payment provider, a mail service in your name), the thread is where they ask for it.
Your order page marks the launch transferred. From that point the product is yours the way a car is after the keys change hands: we handed it over running, and keeping it running — the host's bill, its status page, its support — is between you and the host. Bugs in the build itself are a different matter; see Step 7.
Your own domain. The address the host gave you works forever, but most people want yourname.com. Buy the domain from any registrar (Cloudflare, Namecheap, Porkbun — a few dollars a year), then open your host's custom-domain page: on Netlify, Domain management → Add a domain; on Railway, service → Settings → Networking → Custom Domain. The host shows you one or two DNS records — short lines you copy into your registrar's DNS page — and turns the domain on when it sees them, usually within an hour. Each host's own page on this is the best guide; it knows your exact records, and this page does not.
When something goes wrong. Three different problems, three different doors.
The site is down, a deploy failed, the bill looks wrong: that is the host's. Check their status page first (netlifystatus.com, status.railway.com), then their docs and support. The deploy log is the thing to read and the thing to send them.
The product runs but does something wrong: that is a change round. Open your delivered order and press the change-round button; describe the change, and it is quoted before anything is built. The fix lands in the same repository and deploys the same way.
The Launch it for me add-on exists for exactly that. Pick it while your order is being refined or before you accept the quote; your operator does Steps 3 or 4 and hands the result to you as in Step 5. It is priced on the quote as its own line, and it needs git delivery, which the option arranges. Custom domains stay yours either way.