Deploy from GitHub
Connect a GitHub repository and put it online — the step-by-step way and the one-command way.
This is the most common thing people do with Openship: take some code that lives on GitHub and make it a real, working website with its own address. Think of it like this — your code is a recipe, and Openship is the kitchen that cooks it and serves the meal. You point Openship at the recipe once, and it does the rest.
What you need first
- An Openship account (you're already in if you can see the dashboard).
- A GitHub repository with your app in it.
- That's it. You do not need Docker, a server, or any config files — Openship figures those out.
The click-by-click way
Connect your GitHub account (once)
Openship needs permission to read your repository. You only do this one time.
Go to Settings → General and press Connect GitHub. A GitHub window pops up asking "do you allow this?" — say yes. When it closes, you're connected.
Screenshot
Self-hosted: two ways to connect (no Openship account required)
On a self-hosted instance you're never forced through Openship Cloud. The GitHub card in Settings → General offers:
- Openship Cloud GitHub App — the managed App (short-lived tokens, great for remote-server deploys). Optional; it needs an Openship Cloud connection.
- Manual — connect with your own GitHub identity, no Openship in the middle:
ghCLI on the instance — press Log in with GitHub; if the instance hasghauthenticated it's picked up immediately, otherwise run the showngh auth loginon the box and the page detects it automatically.- Your own GitHub OAuth/App (device login) — set
GITHUB_CLIENT_ID(a public client id from a GitHub App/OAuth app you register, with device flow enabled) and Log in with GitHub shows a one-time code +github.com/login/devicelink right in the UI — no terminal, no Openship client id. - A clone token — or just add a personal access token under Clone credentials.
Pick whichever fits; Openship never substitutes its own GitHub identity for yours on a self-hosted box.
Pick the repository you want to deploy
Open the Library page (the "New project" button takes you here too). Choose the Repositories tab — you'll see a list of your GitHub repos. Click the one you want.
Screenshot
Choose where it should run
Openship asks where to run your app. Pick the one that fits:
- Local — on this computer (great for trying things out on the desktop app).
- Server — on one of your own connected servers.
- Cloud — on Openship Cloud, where we run it for you.
If you're just starting, the default choice is fine — you can move it later.
Check the settings and press Deploy
Openship shows a summary: which framework it detected, the build command, and the web address it will use. For most apps you don't change anything here.
Press Deploy.
Tip
See a field you don't recognize? Leave it. Openship's detected defaults are correct for the large majority of apps — you only override things when you have a specific reason.
Watch it go live
You land on the build screen, which streams the logs live — like watching the oven through the glass door. When it finishes, you get a link. Click it, and your app is online. 🎉
Screenshot
Turn on auto-deploy (optional but great)
By default you deploy when you choose to. If you'd like Openship to redeploy every time you push to GitHub, turn on auto-deploy:
Open your project → Source tab → switch on Auto-deploy. From now on, every git push to your
deploy branch rebuilds and ships automatically.
Prefer the terminal?
Everything above works from the CLI too:
# Create a project pointing at your repo
openship project create --name my-app --git-owner your-name --git-repo my-app
# Ship it
openship deploy
# Optional: redeploy on every push
openship project git auto-deploy my-app --enableIf something goes wrong
“Connect GitHub” does nothing / no repos show up
Your GitHub connection didn't finish, or Openship has no permission for that repo. Go back to Settings → General, disconnect, and connect again — and when GitHub asks which repositories to grant, make sure your repo is included.
The build failed
Open the build screen and read the last few red lines — that's the real reason. Most first-time failures are one of: a missing build command, a missing environment variable, or the app listening on the wrong port. See Troubleshooting → Deployments for the fixes.
What next?
Core concepts
The plain-language vocabulary the rest of the docs use — organizations, projects, deployments, services, servers, domains, environments, and runtimes.
Deploy a local folder
Put an app online straight from a folder on your computer — no GitHub required. The desktop picker, the browser upload, and the one-command CLI way.