Services

A service is a workload or managed resource running inside an environment. Simplifyd Cloud supports these service types:

Creating a Docker service

1. Click + Add at the top right of the canvas, or press Cmd + K, and choose Docker Image.
2. In the service creation panel, enter the Docker image name (e.g. nginx:latest or ghcr.io/my-org/my-app:main).
3. Configure resources and click Add.
4. An Apply Changes bar appears at the bottom — click Apply to deploy.

Docker service settings

Open the service panel → Settings tab to configure:

Private registry credentials

By default, Docker services pull images from public registries without authentication. If your image is hosted in a private registry, you need to provide credentials so the platform can pull it at deploy time.

Supported registries

Any registry that supports standard Docker authentication is supported:

Configuring credentials

1. Open the service panel → Settings tab.
2. Under Source, find the Registry Credentials section.
3. Click Add credentials.

4. Enter your username and password (or token), then click Set credentials.

The credentials are saved and used automatically on the next deployment.

To update credentials, click Edit and re-enter them. To remove them entirely, open the form and click Clear credentials.

Credential format by registry

Image format

When using a private registry, include the full registry domain in your image path:

ghcr.io/your-org/your-image:tag
registry.gitlab.com/your-group/your-project/image:tag
your-dockerhub-username/private-repo:latest

For Docker Hub private images the domain can be omitted:

your-username/private-image:latest

Security

Credentials are encrypted at rest using AES-256-GCM. Only the username is returned in API responses — the password is never exposed after it is saved. Credentials are decrypted only at deployment time when the image is pulled.

Creating a Postgres service

1. Click + Add and choose Postgres Database.
2. Set the name and the storage size.
3. Click Apply in the Apply Changes bar.

DATABASE_URL is set automatically and can be referenced from other services. See Postgres for databases, users, parameters, and resizing.

Creating a MySQL service

1. Click + Add and choose MySQL.
2. Choose how many servers and routers to run, and set the storage.
3. Click Apply.

A MySQL service runs two kinds of node: servers, which hold your data, and routers, which take connections from your app and pass them to the right server. Both are billed, so a 3-server cluster with 1 router is 4 nodes.

Your app connects to the router, never to a server directly. See MySQL for how many of each to run, connecting, and what is not supported yet.

Creating a Redis service

1. Click + Add and choose Redis.
2. Pick a mode and set the storage.
3. Click Apply.

Cluster mode runs a follower for every leader, so a 3-node cluster is 6 nodes and is billed as 6. Standalone is the cheapest and is enough for a cache.

The connection details appear in the service panel → Settings tab → Connection once the service is running. Redis is reachable over private networking only.

Creating a Kafka service

Kafka lets your services send and receive streams of messages. Use it for event streaming, background job queues, or passing data between services.

1. Click + Add and choose Kafka.
2. Pick a mode (see below).
3. Set the storage per broker — how much disk each node gets for message logs.
4. Click Apply in the Apply Changes bar to create the cluster.

Choosing a mode

Standalone is cheaper and starts faster, but if the node fails you lose the messages on it. Cluster keeps copies on more than one node, so it survives a node failure.

If you choose cluster mode, you also set:

Connecting to Kafka

Open the service panel → Settings tab → Connection. You will see a bootstrap.servers address once the cluster is running.

Use that address in your Kafka client. For example:

bootstrap.servers=my-kafka.abc12.simplifyd.internal:9092

Kafka is reachable from other services in the same environment over private networking. It is not reachable from the public internet.

A new cluster takes a few minutes to start. Until it is ready, the service shows as starting and no connection address is shown.

Service panel

Clicking any service node opens the service panel on the right side of the canvas. The panel has four tabs:

Renaming a service

Click the pencil icon next to the service name in the panel header. Service names are used in reference variables — for example ${{my-service.PORT}}.

Ingress / public endpoints

To expose a service on the internet, configure ingress in the service Settings tab:

1. Find the Networking section.
2. Click Generate Domain for a hostname assigned to you, Custom Domain for one of your own, or TCP Proxy / UDP Proxy for a raw port.
3. Enter the internal port your service listens on.
4. Click Apply to activate the endpoint.

HTTP and gRPC endpoints get a hostname and HTTPS automatically. TCP and UDP endpoints get a public port instead — see TCP and UDP endpoints, which also covers restricting who can connect.

The public URL or port appears in the Settings tab once the deployment is live.

Healthchecks

Healthchecks tell Simplifyd Cloud when your service is starting, ready to receive traffic, or needs to be restarted. Simplifyd Cloud supports three probe types: startup, readiness, and liveness.

Configure them in the service panel → Settings tab → Deploy section → Health checks, where each of Liveness Probe, Readiness Probe, and Startup Probe has its own + Add button.

See the Healthchecks page for full configuration details, recommended patterns, and code examples.

Config file mounts

Configs let you inject static text files (e.g. Caddyfile, nginx.conf, application.yaml) directly into a service without building a custom Docker image. The file content is stored on Simplifyd Cloud and mounted at a path you choose every time the service is deployed.

Adding a config

1. Open the service panel → Settings tab.
2. Scroll to the Configs section and click Add Config.
3. Fill in the dialog:
   • Name — a human-readable label (e.g. Caddyfile).
   • Mount Path — absolute path inside the service where the file should appear (e.g. /etc/caddy/Caddyfile).
   • Content — paste or type the file content in the editor. The editor highlights syntax automatically based on the file extension.
4. Click Save Config.

Editing a config

Click the pencil icon next to an existing config to open it in the same dialog. Edit any field and click Save Config. Redeploy the service to apply the new content.

Deleting a config

Click the trash icon next to a config and confirm. Redeploy the service to remove the mount from the service.

Variable interpolation

Config content can reference service variables using the ${{VAR_NAME}} syntax. Variables are resolved at deploy time, so the stored content always keeps the original placeholders and they are re-evaluated on every deployment.

# Caddyfile
${{SERVICE}}.${{ENVIRONMENT}}.internal {
    reverse_proxy localhost:${{PORT}}
}

Available built-in variables: ${{SERVICE}}, ${{ENVIRONMENT}}, ${{PROJECT}}. Any variable you have set on the service (e.g. ${{DATABASE_URL}}, ${{PORT}}) is also available. Unmatched placeholders are left as-is.

Ephemeral storage

Ephemeral storage attaches a temporary volume to a path in your container, giving it more room than the container image alone.

1. Open the service panel → Settings tab → Storage.
2. Click Add Storage.
3. Set a name, a mount path inside the container (e.g. /var/cache), and a size in GB.
4. Click Apply.

Use it for a disk cache, a scratch directory for large temporary files, or an index that is rebuilt on boot. Storage is billed on the size you allocate, not on what you use.

Stopping, starting, and restarting a Postgres service

Postgres services support three lifecycle controls available from the Deployments tab dropdown menu on the active deployment.

Stop

Stopping a service pauses the database and drops active connections. Your data is preserved.

To stop a Postgres service:

1. Open the service panel → Deployments tab.
2. Click the ⋮ menu on the active deployment.
3. Click Stop and confirm.

The deployment card will show an amber STOPPED badge and the message "Service hibernated — storage billed, compute paused".

Billing while stopped

When a service is stopped, a new deployment record is created with vCPU and memory set to zero. The billing system uses the deployment record to calculate charges, so:

Start

To resume a stopped Postgres service:

1. Open the service panel → Deployments tab.
2. Click the ⋮ menu on the active deployment.
3. Click Start.

The service transitions from stopped to pending, then to running. No data is lost.

Restart

Restarting performs a clean service restart.

1. Open the service panel → Deployments tab.
2. Click the ⋮ menu on the active deployment.
3. Click Restart and confirm.

Active connections are briefly interrupted (typically under 30 seconds). Billing is unaffected.

Redeploying while stopped

If you click Redeploy while a service is stopped, the service is started automatically and a new deployment is created with the configured vCPU and memory. You do not need to manually start it first.

Deleting a service

Open the service panel → Settings tab → scroll to the bottom and click Delete Service. Confirm the deletion. The change is staged — click Apply to permanently remove the service and all its deployments.