DocsStartCreating services

Creating services

A service is your app, database or site running in the cloud. Every service is created through the same wizard and lives on the Services tab of the console.

Open console.muerte.cloud and go to Services to start.

Service types#

FieldDescription
Static siteHTML/CSS/JS and builds from React, Vue, Astro and other frontend frameworks
Web serviceAn app or API reachable from the internet over a domain
Private serviceRuns inside your environment only, never published publicly
WorkerBackground processing: queues, mailers, long tasks. No domain
Cron serviceA container that starts on a schedule and exits
PostgreSQL / Redis / MongoDBManaged databases with ready-to-use credentials

Step by step#

  1. 1
    Open the creation wizard
    Go to ServicesCreate service and pick a type. The type decides which settings you see next — a domain and port are only requested for web services.
  2. 2
    Choose a code source

    Applications support three sources:

    • Catalog — ready-made apps deployed in one click (panels, CMS, game and media servers). Nothing to configure.
    • Repository — connect a Git account, pick a repository and branch. Each new commit to that branch can trigger a rebuild.
    • Archive — upload a .zip with your project. Handy when the code is not in Git.

    Databases skip this step.

  3. 3
    Configure the build
    The build type defines how your code turns into a running service. When unsure, keep Railpack — it detects the language (Node.js, PHP, Python, Go, Java and more) and picks build commands.
  4. 4
    Pick resources and plan
    Choose the plan the service is created under, then CPU and RAM. Insufficient RAM during the build is the single most common cause of failures. The console shows how many slots and resources the plan has left.
  5. 5
    Add environment variables
    Set anything that must not live in code — API keys, connection strings, run mode — as KEY=value pairs, one per line. Values are masked in the UI and never printed into build logs. Changing variables requires a redeploy.
  6. 6
    Set port and domain (web services)
    Enter the port your app listens on inside the container — for example 3000 for Node.js, 8000 for Python, 80 for nginx. A technical domain is created and all traffic is routed to that port.
  7. 7
    Create and watch the first build
    Click Create. The service appears with a building status and the Deployments tab streams the live build log. On success the status becomes Running and the domain goes live.

Build types

FieldDescription
RailpackUniversal auto-detecting builder — the recommended default
NixpacksAlternative auto-builder, useful for unusual stacks
Paketo BuildpacksEnterprise builds following the Cloud Native Buildpacks standard
DockerfileYour repository ships its own Dockerfile and you want full control
StaticPrebuilt static files, no server process needed
Wrong port?
If the port does not match your process, the domain answers with a gateway error. Change it on the Settings tab and redeploy.

What to set up right after creating#

Managing a service#

FieldDescription
OverviewStatus, resources, quick actions: start, stop, redeploy.
DeploymentsBuild history, logs and rollbacks.
LogsLive application logs.
MetricsCPU and memory consumption.
VariablesEnvironment variables.
SettingsPort, domains, volumes, deletion.

FAQ#

Can I change the build type later?

Yes, on the Settings tab. Trigger a redeploy afterwards.

What happens when a service is stopped?

The container shuts down and resources are released. Data in volumes and databases is kept, and starting the service again needs no rebuild.

Is deletion reversible?

No. The container, domains and attached volumes are removed. Only backups already exported to object storage remain.

If the build fails

Expand the deployment in the history and read the log. The Copy button next to the log is useful when you need to send it to support.

text
# typical failure: not enough RAM during install
Killed
error Command failed with exit code 137