Next.js
A Next.js app with server rendering and API routes, ready to run as a web service.
- Web service
Apps
Connect a repo. Stop thinking about servers.
Deploy web services and static sites without managing infrastructure. Pick a repository and branch and let Cosmoner build, run, and keep your app in sync — or deploy a container image you already have.
- 3 ways to deploy
- Every push deploys, if you want
- Domain included
- Live console and logs
acme-api · maindeployed
# push to maina3f91c2 fix: retry on timeout$ cosmoner builddetected: Node.js 22building… 42sdeployed · acme-api.cosmoner.app
- Build logs42s
- Runtime logsstreaming
- Live consoleavailable
BUILDS
2
Automatic, Dockerfile
DEPLOYS
On push
For the branch you selected
RUNTIMES
2
Web services and static sites
ACCESS
Logs + console
Build and runtime kept apart
Git integration
Git auto-sync, built in
Enable auto-deploy and every push to your selected branch is synchronized with Cosmoner, built, and deployed automatically — no pipeline file, no runner to maintain.
- 01
Connect your repository
Connect GitHub, GitLab or Bitbucket, then choose the repository and branch you want to deploy. The build strategy is detected from what is already in the repo.
- 02
Push your code
Keep working in your git provider with the development flow you already use. Nothing new to run locally, and no pipeline to define.
- 03
Sync and deploy
Cosmoner detects pushes to the selected branch, starts a fresh build, and rolls out the new deployment automatically.
No code yet?
Start from a template
Copy a starter app to your GitHub and deploy your copy in a few clicks. It is a real app from the first push, ready for you to build on.
Astro
A fast content site built with Astro and served as static files from the CDN.
- Static site
Hono API
A small TypeScript HTTP API on Hono, with a health check and JSON routes.
- Web service
What comes with an app
Managed, and still inspectable
Not managing servers should not mean losing sight of what is running. Builds, logs, metrics, and a console are part of the product rather than an add-on.
Flexible builds
Let Cosmoner detect your stack and build it for you, or build from the Dockerfile already in your repository.
Automatic · Dockerfile
Or deploy a container image
Skip the build entirely and deploy an image you already have. Repositories from a Cosmoner registry are offered directly, with no pull secret to configure.
Your registries, Docker Hub or GHCR
Services and static sites
Run long-lived web services or build static sites that are served from a CDN, all through the same deployment flow.
One flow, two runtimes
Domains included
Launch immediately on a Cosmoner subdomain or connect a domain you already manage in your project, with the records created for you.
Subdomain now, your name later
Variables and secrets
Configure environment variables, hide sensitive values, and link reusable project variables and vault secrets so nothing is pasted twice.
Resolved at deploy time
Logs, metrics, and a live console
Follow deployment activity, inspect app metrics, read separate build and runtime logs, and open a console against the running service when you need deeper access.
Without leaving the panel
Deploy from an image
A build is optional, not required
When the image is already built — by your CI, or by hand — deploy that instead. Repositories from a registry you created here appear at the top of the form and fill the image path in for you.
- No registry username, no access token, and no pull secret to rotate.
- Nothing to re-enter when the same image is deployed to a second app.
- Docker Hub and GHCR work too — public images as they are, private ones with a connected integration or a stored token.
- Environment variables, domains, and vault links work the same either way.
New app · container imageYour registries
- acme-labs/api1.4.2 · eu-north-1
- acme-labs/worker0.9.7 · eu-north-1
# selected, path filled inregistry.cosmoner.com/acme-labs/api:1.4.2# credentials required: none
When something breaks
Three places to look, and they differ
A failed build and a crashing process are different problems, so they are not in the same stream. Deployment activity ties both back to the change that caused them.
Build logs
Everything the builder did, per deployment. Where a missing dependency or a failing compile step shows up.
Runtime logs and metrics
What the running service is writing and how it is behaving, kept separate from the build that produced it.
Live console
A shell against the deployed service for the cases where reading logs is not enough to work out what is wrong.
One project
What it plugs into
An app is rarely alone. The image it runs, the domain it answers on, and the configuration it reads are all in the same project.
Container RegistryDeploy your own imagesPrivate repositories offered in the deploy form, with no pull secret to create.DomainsAnswer on your own nameStart on a Cosmoner subdomain and attach a domain from the project when you are ready.Secrets ManagerConfiguration without copiesLink vault secrets as environment variables, resolved fresh on every deployment.
What it costs
Priced per instance, charged per day held
A service is billed on the instance size you pick, a static site on a flat rate. Both are prorated from the moment you deploy, and removing them credits back the days you did not use.
- Web service
- Per instance size
- Each size sets its own vCPU, memory, and bandwidth allowance, and carries its own monthly price. The wizard shows the price beside every size before you deploy.
- Static site
- USD 3 / month
- One flat rate per site, including the global CDN in front of it. No instance size to pick and no bandwidth meter.
- Builds and deploys
- USD 0
- Building an image and rolling out a release are not metered — deploy as often as you push.
Every instance size shows its monthly price in the deploy wizard, with the prorated amount you will be charged today before you confirm.
Questions worth answering up front
Build strategies, environment variables, and the deployment API are covered in the docs.
- Do I have to write a build config?
- No. Cosmoner detects most stacks on its own. If you would rather be explicit, it will build from the Dockerfile already in your repository instead.
- Does every push deploy?
- Only if you enable auto-deploy, and only for the branch you selected. Pushes to other branches are left alone, so a feature branch does not reach production by accident.
- Can I deploy without connecting GitHub?
- Yes — deploy a container image instead. Images in a Cosmoner registry appear in the deploy form and need no credentials; Docker Hub and GHCR work too, with a connected integration or a token for private images.
- How do I get sensitive values into the app?
- Link them from the project vault rather than pasting them. The variable shows as linked instead of showing a value, and each deployment resolves the current one.
- Can I get a shell on a running app?
- Yes. Deployed services have a live console for inspecting and troubleshooting the running application. For full OS-level control, Cloud Hosting is the product to reach for instead.
- What can I see when a deployment fails?
- Build and runtime logs are kept separate, so a failed build and a crashing process do not look alike. Deployment activity records what changed and when.