This is the full developer documentation for Sliplane Docs # What is Sliplane? > Learn how Sliplane works and how it can help you to focus on shipping instead of managing your servers. **Sliplane is a simple and cost effective cloud platform for running applications, databases, and storage without managing infrastructure yourself.** Use Sliplane to deploy services from GitHub or container registries, run them on managed servers, add managed PostgreSQL databases, and store files in S3-compatible object storage. The platform handles the production basics around builds, deploys, health, logs, metrics, backups, SSL, and access control so you can focus on shipping. Sliplane started out as a Docker hosting platform, and containers are still at the heart of what we do. But you no longer need to know anything about Docker to deploy with us, and the platform now covers more of your stack — from [deploying your apps](/services/deploying-a-service) to [managed PostgreSQL databases](/databases/overview) and [object storage](/object-storage/getting-started). One of Sliplane’s core features is continuous deployment. Connect a GitHub repository, and Sliplane can automatically build and deploy your application on every new commit. Simple Pricing Sliplane charges **per server**, not per service. Host your frontend, backend, and background services on one server for a single price starting at **€9/month + VAT**. We bill per hour, so you only pay for the time your server exists. [Learn more about billing](/teams/billing) [Services ](/services/deploying-a-service)Deploy your first service from GitHub or a registry, with or without a Dockerfile [Servers ](/servers/create-a-server)Learn how to create servers in Sliplane [Object Storage ](/object-storage/getting-started)Store files and uploads in S3-compatible buckets managed through Sliplane [Databases ](/databases/overview)Managed PostgreSQL databases with backups, metrics, and access control ## FAQ [Section titled “FAQ”](#faq) Here you can find answers to the most common questions we get about Sliplane. If you have any other questions, please [contact us](mailto:support@sliplane.io?subject=FAQ) ### How much does Sliplane cost? [Section titled “How much does Sliplane cost?”](#how-much-does-sliplane-cost) Sliplane charges per server. Host unlimited services for one price. Servers start at €9/month + VAT with per-hour billing (you only pay for the time your server exists). See our [detailed billing guide](/teams/billing) for more information. ### Where are my servers hosted? [Section titled “Where are my servers hosted?”](#where-are-my-servers-hosted) Servers in Germany and Finland run on infrastructure from [Hetzner GmbH](https://hetzner.com). Servers in the US and Singapore run on Datapacket and Latitude. In all locations you get stable and powerful hardware at highly competitive rates. ### Can I bring my own server? [Section titled “Can I bring my own server?”](#can-i-bring-my-own-server) No, we provide a fully managed service, so you don’t need to deal with server management at all. A public Sliplane agent that you can install on your own infrastructure does not exist. ### Why should I use Sliplane? [Section titled “Why should I use Sliplane?”](#why-should-i-use-sliplane) Sliplane is built for shipping real applications quickly without taking on the operational work of managing servers yourself. You can deploy code with or without a Dockerfile, run multiple services on one server, add managed PostgreSQL databases, store files in S3-compatible Object Storage, and keep the setup affordable with simple per-server pricing. ### Do I need to know Docker to use Sliplane? [Section titled “Do I need to know Docker to use Sliplane?”](#do-i-need-to-know-docker-to-use-sliplane) No. You can deploy straight from a GitHub repository without writing a Dockerfile — Sliplane detects your application’s stack and builds it for you using [Railpack](https://railpack.com/). If you do want full control over the build, you can add a Dockerfile and Sliplane will use it instead. ### How do I get started? [Section titled “How do I get started?”](#how-do-i-get-started) Head over to [Sliplane](https://sliplane.io) and sign up with your GitHub account. # Deleting Your Account > How to permanently delete your Sliplane account and what happens to your data. You can permanently delete your Sliplane account from the app. Your personal data is removed, and any organizations where you are the only member or only owner are deleted along with all services, servers and volumes. ## Before you start [Section titled “Before you start”](#before-you-start) Before you can delete your account, ensure you have addressed the following: * **Active servers**: delete all servers in those organizations first. See [Deleting a Server](/servers/deleting-a-server). * **Open invoices**: pay any outstanding invoice first. If you are the sole owner of a team that has other members, the team and everything in it will be deleted together with your account. ## How to delete your account [Section titled “How to delete your account”](#how-to-delete-your-account) 1. Go to your account settings and click **Delete Account**. 2. We send a confirmation link to your account email. Open it within 24 hours. 3. After you confirm, your deletion is **scheduled for 24 hours later**. You’ll receive an email confirming the scheduled time. 4. During this 24-hour grace period you can cancel the deletion from your account settings (**Cancel Deletion**). Once the grace period ends, deletion starts and can no longer be cancelled. 5. When the deletion has completed, we send a final confirmation email to the address you signed up with, then remove your contact from our mailing system. Once the 24-hour grace period ends, deletion is permanent. We cannot restore an account, a team, a server, a service or a volume after the job has run. If you change your mind during the grace period, use **Cancel Deletion** before the scheduled time. # Email Notifications > Manage your email notification preferences in Sliplane. You can configure which emails you receive from Sliplane in your [account settings](https://sliplane.io/app/account). ## Notification Categories [Section titled “Notification Categories”](#notification-categories) There are three types of email notifications you can toggle on or off: * **Product Updates** - New features, roadmap updates, and general product news. * **Content** - New blog posts, tools, and resources. * **Customer Insights** - Invitations to leave feedback or take surveys. ## Updating Your Preferences [Section titled “Updating Your Preferences”](#updating-your-preferences) 1. Go to your [account settings](https://sliplane.io/app/account) 2. Toggle the notification categories you want to receive 3. Click **Save** to apply your changes # SSH Keys > Manage your SSH keys for accessing services via SSH in Sliplane. You can manage all of your SSH keys in the [SSH Keys tab](https://sliplane.io/app/account/ssh) of your account settings. SSH keys are used to connect to your services via SSH. Note If you don’t have an SSH key yet, follow [GitHub’s guide](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) to generate one. ## Adding an SSH Key [Section titled “Adding an SSH Key”](#adding-an-ssh-key) 1. Go to [Account Settings > SSH Keys](https://sliplane.io/app/account/ssh) 2. Click **Add SSH Key** 3. Enter a name for your key 4. Paste your **public** key (e.g. the contents of `~/.ssh/id_ed25519.pub`) 5. Click **Save** After adding a key, you can attach it to any service to enable SSH access. See [SSH Access](/services/ssh) for details. ## Editing an SSH Key [Section titled “Editing an SSH Key”](#editing-an-ssh-key) You can rename an SSH key by clicking the edit icon next to the key in the list. ## Deleting an SSH Key [Section titled “Deleting an SSH Key”](#deleting-an-ssh-key) To delete a key, click the delete icon next to it. You’ll be asked to confirm before the key is removed. Caution Deleting an SSH key will remove it from all services it is attached to. You will lose SSH access to those services until you attach a new key. # Getting Started with the Sliplane API > Learn how to get started with the Sliplane API. The Sliplane API can be used to manage resources in your organization programmatically. If you want to try it out, go to your team settings in the Sliplane dashboard and create a new API key. You can find out more about the API in the [API documentation](https://ctrl.sliplane.io). # Access Control > Control who can manage and connect to your Sliplane database. Access control lets you restrict which IP addresses can connect to your database. Only the IP ranges you add to the allowlist can reach the database, and everything else is blocked. Open your database in the Sliplane dashboard and go to the **Access Control** tab to manage the list. ## How It Works [Section titled “How It Works”](#how-it-works) Only the IP ranges listed in the allowlist can connect to your database. Any address that does not match a rule is blocked. Caution If the list is empty, **all access is blocked**. Add at least one rule to allow connections. ## Adding a Rule [Section titled “Adding a Rule”](#adding-a-rule) 1. Open your database and go to the **Access Control** tab 2. Click **Add Rule** 3. Enter an IP address or CIDR range 4. Optionally add a comment to describe the rule (e.g. “Office VPN” or “CI server”) 5. Save your changes Changes take effect shortly after saving. ## CIDR Notation [Section titled “CIDR Notation”](#cidr-notation) Rules use [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) to specify IP ranges, for both IPv4 and IPv6: | Rule | What it matches | | ---------------- | --------------------------------------------------------- | | `203.0.113.10` | A single IPv4 address | | `203.0.113.0/24` | All IPs from 203.0.113.0 to 203.0.113.255 (256 addresses) | | `0.0.0.0/0` | All IPv4 addresses | | `2001:db8::1` | A single IPv6 address | | `2001:db8::/48` | An IPv6 range | | `::/0` | All IPv6 addresses | Common IPv4 subnet sizes: * `/32` - single IP (same as specifying the IP without a prefix) * `/24` - 256 addresses (e.g. `192.168.1.0/24`) * `/16` - 65,536 addresses (e.g. `172.16.0.0/16`) ## Managing Rules [Section titled “Managing Rules”](#managing-rules) You can update or delete existing rules at any time. Changes take effect shortly after saving. Each rule can have an optional comment to help you remember what it is for, which is especially useful when managing multiple rules. Tip To allow connections from anywhere, add `0.0.0.0/0` to the list. This permits all IPv4 addresses, so only use it when your database is protected by other means such as strong credentials. # API > Manage your Sliplane databases programmatically over the REST API. Everything you can do with a database in the dashboard is also available over the REST API: create and delete databases, pause and resume them, rotate credentials, restore to a point in time, and read logs and metrics. For the full request and response schema, please check out the [API documentation](https://ctrl.sliplane.io/#tag/postgres). # Backups > Restore a Sliplane database to any point in time within the backup window. Sliplane supports Point-in-Time Recovery (PITR) which lets you restore your database to *any* moment within the available backup window. Backups are retained for **7 days** on all tiers. Need a longer window? [Contact us](mailto:support@sliplane.io) to request extended retention. ## Restoring a database [Section titled “Restoring a database”](#restoring-a-database) Open your database in the Sliplane dashboard and go to the **Backups** tab. 1. Choose a **Restore point**. You can pick any time between the earliest and the latest time shown. 2. Confirm the restore. Restoring creates a **new database** at your current configuration. Your existing database is left completely untouched, so you can compare the two or keep the original running while you verify the restore. The new database is billed hourly at the same rate as your current configuration. See [Pricing](/databases/pricing) for the rate that applies to your size. # Getting Started > Managed PostgreSQL databases with backups, SSL, metrics, and access control, managed through Sliplane. This page shows you how to create a Sliplane database and connect to it from your application in the fastest way. ## Create a database [Section titled “Create a database”](#create-a-database) To create a database, follow these steps: 1. In the Sliplane dashboard, go to [**Databases**](https://sliplane.io/app/databases). 2. Click **Create Database**. 3. Choose a **name**, **region**, **compute** size, and **storage** size. See [Pricing](/databases/pricing) for what each option costs. 4. Click **Create Database**. Your database is ready to use once it finishes provisioning which takes around 30 seconds. Open it to find its connection details. ## Connect to your database [Section titled “Connect to your database”](#connect-to-your-database) You can connect to your database using any PostgreSQL client, including command-line tools, language drivers, and graphical clients. All connections to Sliplane databases support TLS encryption. For protection against man-in-the-middle attacks, connect with `sslmode=verify-full`, which validates our certificate and hostname. ### Configure the environment [Section titled “Configure the environment”](#configure-the-environment) The fastest way to connect to your database is to use the **Connection URI**, which contains all the information needed to connect. ```txt postgres://jonas:pAsSworD123@xxxxxx.sliplane.app:1234/mydb?sslmode=verify-full&sslrootcert=system ^ ^ ^ ^ ^ user -| | |- host port -| |- database | |- password ``` Copy the Connection URI from the Sliplane dashboard where your database is located and set it as an environment variable `DATABASE_URL`. * Linux or macOS ```bash export DATABASE_URL="postgres://USER:PASSWORD@HOST:PORT/DATABASE?sslmode=verify-full&sslrootcert=system" ``` * Windows Command Prompt ```bat setx DATABASE_URL "postgres://USER:PASSWORD@HOST:PORT/DATABASE?sslmode=verify-full&sslrootcert=system" ``` * PowerShell ```powershell $Env:DATABASE_URL="postgres://USER:PASSWORD@HOST:PORT/DATABASE?sslmode=verify-full&sslrootcert=system" ``` ### Quick starts [Section titled “Quick starts”](#quick-starts) With the environment variable in place, you can connect from the `psql` CLI, any PostgreSQL driver, or ORMs. Here are a few examples to get you started. * psql ```bash # Connect to your database psql "$DATABASE_URL" # Or run a single query psql "$DATABASE_URL" -c "SELECT version();" ``` * JS (pg) Caution Please remove `sslrootcert=system` from the connection URI and configure `DATABASE_URL` again, as `pg` does not recognize that parameter and will throw an error. `sslrootcert=system` is `pg`’s default behavior. ```javascript import { Client } from "pg" const client = new Client({ connectionString: process.env.DATABASE_URL }) await client.connect() const { rows } = await client.query("SELECT * from pg_stat_ssl") console.log(rows[0]) // { ssl: true, ... } await client.end() ``` * JS (postgres) Caution Please remove `sslrootcert=system` from the connection URI and configure `DATABASE_URL` again, as `postgres.js` does not recognize that parameter and will throw an error. `sslrootcert=system` is `postgres.js`’s default behavior. ```javascript import postgres from "postgres" const client = postgres(process.env.DATABASE_URL) const [ ssl ] = await client`SELECT * from pg_stat_ssl` console.log(ssl) // { ssl: true, ... } await client.end() ``` * Drizzle Caution Please remove `sslrootcert=system` from the connection URI and configure `DATABASE_URL` again, as `postgres.js` does not recognize that parameter and will throw an error. `sslrootcert=system` is `postgres.js`’s default behavior. ```javascript import { drizzle } from "drizzle-orm/postgres-js" import { sql } from "drizzle-orm" import postgres from "postgres" const client = postgres(process.env.DATABASE_URL) const db = drizzle(client) const result = await db.execute(sql`SELECT * from pg_stat_ssl`) console.log(result[0]) // { ssl: true, ... } await client.end() ``` * Python ```python import os import psycopg with psycopg.connect(os.environ["DATABASE_URL"]) as conn: with conn.cursor() as cur: cur.execute("SELECT version()") print(cur.fetchone()) ``` * Go ```go package main import ( "context" "fmt" "os" "github.com/jackc/pgx/v5" ) func main() { ctx := context.Background() conn, _ := pgx.Connect(ctx, os.Getenv("DATABASE_URL")) defer conn.Close(ctx) var version string conn.QueryRow(ctx, "SELECT version()").Scan(&version) fmt.Println(version) } ``` * Java Caution JDBC URL is different from the common PostgreSQL URI format. To connect, you need to construct the connection string with the host, port, database, user, and password separately, and set `sslmode` to `verify-full` together with `sslfactory` set to `org.postgresql.ssl.DefaultJavaSSLFactory` so the driver validates our certificate against the JVM’s trusted CAs. * Linux or macOS ```bash export PGHOST="YOUR_DATABASE_HOST" export PGPORT="YOUR_DATABASE_PORT" export PGDATABASE="DATABASE_NAME" export PGUSER="USERNAME" export PGPASSWORD="PASSWORD" ``` * Windows Command Prompt ```bat setx PGHOST YOUR_DATABASE_HOST setx PGPORT YOUR_DATABASE_PORT setx PGDATABASE DATABASE_NAME setx PGUSER USERNAME setx PGPASSWORD PASSWORD ``` * PowerShell ```powershell $Env:PGHOST="YOUR_DATABASE_HOST" $Env:PGPORT="YOUR_DATABASE_PORT" $Env:PGDATABASE="DATABASE_NAME" $Env:PGUSER="USERNAME" $Env:PGPASSWORD="PASSWORD" ``` ```java import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import java.util.Properties; public class HelloPostgres { public static void main(String[] args) throws Exception { String url = String.format( "jdbc:postgresql://%s:%s/%s", System.getenv("PGHOST"), System.getenv("PGPORT"), System.getenv("PGDATABASE")); Properties props = new Properties(); props.setProperty("user", System.getenv("PGUSER")); props.setProperty("password", System.getenv("PGPASSWORD")); props.setProperty("sslmode", "verify-full"); props.setProperty("sslfactory", "org.postgresql.ssl.DefaultJavaSSLFactory"); try (Connection conn = DriverManager.getConnection(url, props); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("SELECT * FROM pg_stat_ssl;")) { if (rs.next()) { System.out.println(rs.getString("ssl")); // "t" } } } } ``` * Linux or macOS ```bash export PGHOST="YOUR_DATABASE_HOST" export PGPORT="YOUR_DATABASE_PORT" export PGDATABASE="DATABASE_NAME" export PGUSER="USERNAME" export PGPASSWORD="PASSWORD" ``` * Windows Command Prompt ```bat setx PGHOST YOUR_DATABASE_HOST setx PGPORT YOUR_DATABASE_PORT setx PGDATABASE DATABASE_NAME setx PGUSER USERNAME setx PGPASSWORD PASSWORD ``` * PowerShell ```powershell $Env:PGHOST="YOUR_DATABASE_HOST" $Env:PGPORT="YOUR_DATABASE_PORT" $Env:PGDATABASE="DATABASE_NAME" $Env:PGUSER="USERNAME" $Env:PGPASSWORD="PASSWORD" ``` #### Detailed guides [Section titled “Detailed guides”](#detailed-guides) The following table lists the official documentation for popular PostgreSQL drivers and ORMs. | Language or framework | Library | | ----------------------- | ----------------------------------------------------------------------------------------------------------- | | JavaScript / TypeScript | [node-postgres (`pg`)](https://node-postgres.com/) | | JavaScript / TypeScript | [postgres.js](https://github.com/porsager/postgres#installation) | | JavaScript / TypeScript | [Drizzle ORM](https://orm.drizzle.team/docs/get-started/postgresql-new/) | | JavaScript / TypeScript | [Prisma ORM](https://www.prisma.io/docs/orm#how-it-works) | | Python | [psycopg](https://www.psycopg.org/psycopg3/docs/) | | Go | [pgx](https://github.com/jackc/pgx) | | Java | [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/documentation/) | | .NET | [Npgsql](https://www.npgsql.org/doc/index.html) | | Ruby | [`pg` gem](https://rubygems.org/gems/pg) | | PHP | [PDO\_PGSQL](https://www.php.net/manual/en/ref.pdo-pgsql.php) | | Rust | [sqlx / tokio-postgres](https://docs.rs/sqlx/latest/sqlx/) | | Laravel | [Eloquent PostgreSQL driver](https://laravel.com/docs/database#configuration) | | Django | [`django.db.backends.postgresql`](https://docs.djangoproject.com/en/stable/ref/databases/#postgresql-notes) | ### Connect with a GUI [Section titled “Connect with a GUI”](#connect-with-a-gui) Prefer a graphical client? Follow one of these quickstarts to connect with your database’s connection details. [pgAdmin ](/databases/gui/pgadmin)Connect to your database with pgAdmin, the official PostgreSQL admin tool. [CloudBeaver ](/databases/gui/cloudbeaver)Connect to your database with CloudBeaver, a browser-based database client. [n8n ](/databases/gui/n8n)Connect to your database with n8n, the open-source workflow automation tool. [Metabase ](/databases/gui/metabase)Connect to your database with Metabase, an open-source business intelligence tool. # Connection with CloudBeaver > Connect to your Sliplane database with CloudBeaver. [CloudBeaver](https://dbeaver.com/docs/cloudbeaver/) is a browser-based database client from the makers of DBeaver. This quickstart shows how to connect it to a Sliplane database. Tip Sliplane has a one-click deploy preset for CloudBeaver. Click the button below to deploy it in seconds and connect to your database without setting up your own server. [Deploy CloudBeaver](https://sliplane.io/app/deploy?presetId=cloudbeaver) ## Before you start [Section titled “Before you start”](#before-you-start) Open your database in the Sliplane dashboard and keep its connection details handy. You will need the **host**, **port**, **database name**, **user**, and **password**. ## Connect [Section titled “Connect”](#connect) 1. Open CloudBeaver and log in. Click the **New Connection** button, then choose **PostgreSQL**. 2. Fill in the connection settings: * **Host** - the host from the dashboard * **Port** - the port from the dashboard * **Database** - the database from the dashboard * **Username** - the user from the dashboard * **Password** - the password from the dashboard 3. Open the **SSL** settings, enable SSL, set the **SSL Mode** to **verify-full**, and set the **SSL Factory** to `org.postgresql.ssl.DefaultJavaSSLFactory` so the driver validates our certificate against the JVM’s trusted CAs.  4. Click **Test** to confirm the details are correct. 5. Click **Create**. Your database appears in the navigator. You can now browse schemas, run SQL, and manage your data from CloudBeaver. # Connection with Metabase > Connect to your Sliplane database with Metabase. [Metabase](https://www.metabase.com/) is an open-source business intelligence tool for exploring your data, building dashboards, and sharing insights. This quickstart shows how to connect it to a Sliplane database. Tip Sliplane has a one-click deploy preset for Metabase. Click the button below to deploy it in seconds and connect to your database without setting up your own server. [Deploy Metabase](https://sliplane.io/app/deploy?presetId=metabase) ## Before you start [Section titled “Before you start”](#before-you-start) Open your database in the Sliplane dashboard and keep the **Connection URI** handy. ## Connect [Section titled “Connect”](#connect) 1. Open Metabase and click **Databases** in the left sidebar, then click **Add a database**. 2. Set **Database type** to **PostgreSQL**. 3. Fill **Connection string** with the **Connection URI** from the dashboard. 4. Enable **Use a secure connection (SSL)**, set **SSL Mode** to **verify-full**, and add `sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory` under **Additional JDBC connection string options** so the driver validates our certificate against the JVM’s trusted CAs.  5. Click **Save**. Metabase connects and begins syncing your database. You can now explore your tables, write SQL questions, and build dashboards from your data in Metabase. # Connection with n8n > Connect to your Sliplane database with n8n. [n8n](https://n8n.io/) is an open-source workflow automation tool. You can use a Sliplane database with n8n in two ways: as n8n’s own backing database (recommended for self-hosting), or as a data source inside a workflow through the Postgres node. Tip Sliplane has a one-click deploy preset for n8n. Click the button below to deploy it in seconds and connect to your database without setting up your own server. [Deploy n8n](https://sliplane.io/app/deploy?presetId=n8n) ## Before you start [Section titled “Before you start”](#before-you-start) Open your database in the Sliplane dashboard and keep its connection details handy. You will need the **host**, **port**, **database name**, **user**, and **password**. ## Use as n8n’s backing database [Section titled “Use as n8n’s backing database”](#use-as-n8ns-backing-database) By default, self-hosted n8n stores its workflows, credentials, and execution data in a local SQLite file. For production you should use a database like PostgreSQL instead, so your data lives in a managed database with backups and survives container restarts. Point n8n at your Sliplane database by setting the following environment variables on your n8n service: ```bash DB_TYPE=postgresdb DB_POSTGRESDB_HOST=YOUR_DATABASE_HOST DB_POSTGRESDB_PORT=YOUR_DATABASE_PORT DB_POSTGRESDB_DATABASE=DATABASE_NAME DB_POSTGRESDB_USER=USERNAME DB_POSTGRESDB_PASSWORD=PASSWORD DB_POSTGRESDB_SSL_CA= ``` Setting `DB_POSTGRESDB_SSL_CA` lets n8n verify the database server’s TLS certificate. Paste the CA certificate as the value below: CA certificate ```text -----BEGIN CERTIFICATE----- MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4 WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+ 0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ 3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5 ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq 4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc= -----END CERTIFICATE----- ``` Restart n8n after setting these. On the next start, n8n runs its migrations against your database and uses it for all data. Tip If you deployed n8n on Sliplane, you can open your dashboard and set them in the **Environment Variables**:  After adding, click the **Save and redeploy** button to apply the new environment variables. ## Use in a workflow with the Postgres node [Section titled “Use in a workflow with the Postgres node”](#use-in-a-workflow-with-the-postgres-node) If you instead want to read from and write to a Sliplane database as part of a workflow, add a Postgres node and configure a credential. 1. Open n8n. In the left sidebar, click **+** then **Credentials**. 2. Search for and select **Postgres**. 3. Fill in the connection settings: * **Host** — the host from the dashboard * **Database** — the database from the dashboard * **User** — the user from the dashboard * **Password** — the password from the dashboard * **Port** — the port from the dashboard 4. Set **SSL** to **require**.  5. Click **Save**. n8n tests the connection and confirms it succeeded. You can now add a **Postgres** node to any workflow, select this credential, and run queries against your database. # Connection with pgAdmin > Connect to your Sliplane database with pgAdmin. [pgAdmin](https://www.pgadmin.org/) is the official open-source administration and management tool for PostgreSQL. This quickstart shows how to connect it to a Sliplane database. Tip Sliplane has a one-click deploy preset for pgAdmin. Click the button below to deploy it in seconds and connect to your database without setting up your own server. [Deploy pgAdmin](https://sliplane.io/app/deploy?presetId=pgadmin) ## Before you start [Section titled “Before you start”](#before-you-start) Open your database in the Sliplane dashboard and keep its connection details handy. You will need the **host**, **port**, **database name**, **user**, and **password**. ## Connect [Section titled “Connect”](#connect) 1. Open pgAdmin and, in the left **Browser** panel, click **Servers**, then click **Add New Server** in the main panel. 2. On the **General** tab, enter a **Name** for the connection (for example, your database name). 3. Switch to the **Connection** tab and fill in: * **Host name/address** — the host from the dashboard * **Port** — the port from the dashboard * **Maintenance database** — the database from the dashboard * **Username** — the user from the dashboard * **Password** — the password from the dashboard 4. Optionally enable **Save password**. 5. Switch to the **Parameters** tab, and: * Set **SSL mode** to **verify-full** * Add a new parameter **Root Certificate** (`sslrootcert`) with value `system`  6. Click **Save**. pgAdmin connects and shows your database in the **Browser** panel. You can now browse tables, run queries with the Query Tool, and manage your database from pgAdmin. # Limits > Learn about database, connection, and storage limits for Sliplane Databases. ## Database limits [Section titled “Database limits”](#database-limits) The number of databases you can create depends on your team’s database quota. If you need to create more databases than your current quota allows, contact support and we can raise the limit for your team. ## Connection limits [Section titled “Connection limits”](#connection-limits) | Database type | Maximum connections | | ------------------ | ------------------- | | Shared instance | 100 | | Dedicated instance | 300 | ## Compute limits [Section titled “Compute limits”](#compute-limits) Dedicated database instances are available with up to **48 vCPU** and **196 GB RAM**. More compute is available on request. ## Storage limits [Section titled “Storage limits”](#storage-limits) Databases support up to **1 TB** of disk storage. More storage is available on request. # Logging > View logs for your Sliplane database. Sliplane captures logs from your PostgreSQL database. You can easily filter logs within a time range, or by keywords. Open your database in the Sliplane dashboard and go to the **Logs** tab. Use the **From** and **To** time filters to narrow down to a time range, the **Search** filter to match keywords, and toggle **Live** to stream new logs as they arrive.  # Metrics > Monitor resource usage and activity for your Sliplane database. Sliplane shows metrics for each database so you can keep an eye on performance and capacity. ## Viewing metrics [Section titled “Viewing metrics”](#viewing-metrics) Open your database in the Sliplane dashboard and go to the **Metrics** tab. Each chart is interactive: hover to see the exact value at a point in time, and use the controls in the top-right corner to zoom in, zoom out, or reset the view. ## Available metrics [Section titled “Available metrics”](#available-metrics) ### CPU [Section titled “CPU”](#cpu) CPU usage as a percentage of the cores available to your database. Short spikes during queries are normal; sustained high usage is a sign that you should scale up your compute.  ### Memory [Section titled “Memory”](#memory) Memory used by your database against the total memory available. PostgreSQL uses free memory for caching, so some headroom is healthy.  ### Disk [Section titled “Disk”](#disk) Disk space used against the total volume size. Disk usage only grows as your data and indexes grow, so watch this metric to decide when to add more storage.  ### Connections [Section titled “Connections”](#connections) The number of active connections compared to the maximum your database allows. Shared instances allow up to 100 connections and dedicated instances up to 300. If active connections regularly approach the maximum, switch to a dedicated instance to get up to 300 connections.  Use these metrics to decide when to scale up your database’s compute or storage. When you’re ready, [upgrade](/databases/upgrade) with zero downtime. See [Pricing](/databases/pricing) for the available sizes. ## Query stats [Section titled “Query stats”](#query-stats) Query statistics help you find slow and frequently run queries so you can optimize your database. Open your database in the Sliplane dashboard and go to the **Query Stats** tab. Query statistics are based on PostgreSQL’s `pg_stat_statements`. Each table shows the number of calls, mean and max execution time, total execution time, and rows returned for every query. ### Slow queries [Section titled “Slow queries”](#slow-queries) Queries with the highest mean execution time.  ### Top queries [Section titled “Top queries”](#top-queries) Queries consuming the most total execution time.  # Databases > A managed PostgreSQL database on Sliplane — and a guide to everything you can do with it. Sliplane offers fully managed PostgreSQL databases with out-of-the-box SSL/TLS, Point-in-Time Recovery, metrics, query statistics, access control, and more. You get a production-ready PostgreSQL database without the overhead of managing the infrastructure yourself. ## Quick start [Section titled “Quick start”](#quick-start) [Getting Started ](/databases/getting-started)Create your first database and connect to it from psql, any PostgreSQL driver, or an ORM. [pgAdmin ](/databases/gui/pgadmin)Connect to your database with pgAdmin, the official PostgreSQL admin tool. [CloudBeaver ](/databases/gui/cloudbeaver)Connect to your database with CloudBeaver, a browser-based database client. [n8n ](/databases/gui/n8n)Connect to your database with n8n, the open-source workflow automation tool. [Metabase ](/databases/gui/metabase)Connect to your database with Metabase, an open-source business intelligence tool. ## Operate and monitor [Section titled “Operate and monitor”](#operate-and-monitor) [Logging ](/databases/logging)View and filter your database's PostgreSQL logs by time range or keyword, with live streaming. [Metrics ](/databases/metrics)Monitor CPU, memory, disk, and connections, and inspect slow and top queries to decide when to scale. [Backups ](/databases/backups)Restore your database to any point in time within the 7-day backup window using PITR. ## Secure and integrate [Section titled “Secure and integrate”](#secure-and-integrate) [Access Control ](/databases/access-control)Restrict which IP addresses can connect to your database with an allowlist of CIDR ranges. [API ](/databases/api)Manage your databases programmatically through the Sliplane API. ## Plan and scale [Section titled “Plan and scale”](#plan-and-scale) [Pricing ](/databases/pricing)Understand how compute, storage, and billing-period pricing add up. [Limits ](/databases/limits)Review database, connection, compute, and storage limits. # Databases Pricing > Understand how database billing works in Sliplane. Sliplane Databases are billed based on the compute and storage you choose for each database. Note All prices are listed excluding VAT. VAT might be added depending on the billing address you provide during checkout. ## Price [Section titled “Price”](#price) A database’s cost is the sum of its compute size and storage size. You can pay **hourly** (pay as you go), commit **monthly** to save 20%, or commit **yearly** to save 33%. See [Billing period](#billing-period) for details. The prices below are for the **Germany** and **Finland** regions. Other regions vary. The exact price for each compute size, storage size, and region is shown in the dashboard when you create a database, and on the [Sliplane pricing page](https://sliplane.io/#pricing). ### Compute [Section titled “Compute”](#compute) Each database runs on a compute instance. **Shared** instances share CPU cores with other workloads and allow up to 100 connections, a good fit for development and smaller applications. **Dedicated** instances get dedicated CPU cores and allow up to 300 connections, for production and performance-sensitive workloads. #### Shared instances [Section titled “Shared instances”](#shared-instances) | Compute | vCPU | Memory | Hourly | Monthly | Yearly | | -------- | ---- | ------ | -------- | ------- | --------- | | Starter | 1 | 1 GB | €0.03253 | €19.00 | €190.00 | | Base | 1 | 2 GB | €0.04229 | €24.70 | €247.00 | | Medium | 2 | 4 GB | €0.07705 | €45.00 | €450.00 | | Large | 4 | 8 GB | €0.15101 | €88.20 | €882.00 | | X-Large | 8 | 16 GB | €0.29894 | €174.60 | €1,746.00 | | XX-Large | 16 | 32 GB | €0.59480 | €347.40 | €3,474.00 | #### Dedicated instances [Section titled “Dedicated instances”](#dedicated-instances) | Compute | vCPU | Memory | Hourly | Monthly | Yearly | | ------------------- | ---- | ------ | -------- | --------- | ---------- | | Dedicated Base | 2 | 8 GB | €0.17121 | €100.00 | €1,000.00 | | Dedicated Medium | 4 | 16 GB | €0.33900 | €198.00 | €1,980.00 | | Dedicated Large | 8 | 32 GB | €0.67458 | €394.00 | €3,940.00 | | Dedicated X-Large | 16 | 64 GB | €1.34574 | €786.00 | €7,860.00 | | Dedicated XX-Large | 32 | 128 GB | €2.68806 | €1,570.00 | €15,700.00 | | Dedicated XXX-Large | 48 | 196 GB | €4.03038 | €2,354.00 | €23,540.00 | ### Storage [Section titled “Storage”](#storage) Every database includes **10 GB of storage at no extra cost**. Beyond that, storage is billed at **€0.20 per GB per month**. You choose a fixed disk size for each database: | Storage | Hourly | Monthly | Yearly | | ------- | -------- | -------- | --------- | | 10 GB | Included | Included | Included | | 50 GB | €0.01712 | €10.00 | €100.00 | | 100 GB | €0.03425 | €20.00 | €200.00 | | 250 GB | €0.08562 | €50.00 | €500.00 | | 500 GB | €0.17123 | €100.00 | €1,000.00 | | 1 TB | €0.34247 | €200.00 | €2,000.00 | Databases support up to 1 TB of disk storage. See [Limits](/databases/limits) for details. ## Billing examples [Section titled “Billing examples”](#billing-examples) All examples use the **Germany** region and monthly pricing. A small project on a **Starter** shared instance with **50 GB** of storage: * Compute: €19.00 * Storage: €10.00 * **Total: €29.00 per month** A production database on a **Dedicated Large** instance with **250 GB** of storage: * Compute: €394.00 * Storage: €50.00 * **Total: €444.00 per month** ## Billing period [Section titled “Billing period”](#billing-period) Compute and storage are billed **per hour**, the same way servers are billed. You only pay for the time a database exists, from creation until you delete it. You can choose how you commit to a database: * **Hourly** — pay as you go with no commitment. This is the most flexible option and the baseline for the savings below. * **Monthly** — commit for a month and save **20%** compared to paying hourly. * **Yearly** — commit for a year and save **33%** compared to paying hourly. # Upgrade > Upgrade your Sliplane database's compute and storage with zero downtime. You can upgrade your database at any time with **zero downtime**. Open your database in the Sliplane dashboard, go to the **Upgrade** tab, change its compute or storage size, and apply the change. Your database stays available throughout, with no connection interruption. ## Compute [Section titled “Compute”](#compute) Pick a compute size for your database. Toggle between **Shared CPU** and **Dedicated CPU** to see the options for each: * **Shared CPU** — shares CPU cores with other workloads and allows up to 100 connections. A good fit for development and smaller applications. * **Dedicated CPU** — gets dedicated CPU cores and allows up to 300 connections, for production and performance-sensitive workloads. Your current size is labeled **Current**. See [Pricing](/databases/pricing) for the rate of each size and [Limits](/databases/limits) for the maximum compute available. ## Storage [Section titled “Storage”](#storage) Pick the total disk space for your database’s persistent storage. Every database includes 10 GB at no extra cost, and you can grow it up to 1 TB. Storage can only be increased, never reduced. ## Summary and billing [Section titled “Summary and billing”](#summary-and-billing) The **Summary** panel on the right shows the new price before you apply the change. Choose how you want to be billed: * **Hourly** — pay as you go with no commitment. * **Monthly** — commit for a month and save **20%**. * **Yearly** — commit for a year and save **33%**. The panel breaks down compute and storage, then shows the subtotal, VAT (if applicable for your billing address), and total. See [Pricing](/databases/pricing) for full details. ## Apply the upgrade [Section titled “Apply the upgrade”](#apply-the-upgrade) Click **Rescale** to apply the change. The new price applies from the moment the rescale completes, and your database stays online the whole time. # Basic Auth > Secure your apps with basic auth In this tutorial we will take a look at how you can secure your apps hosted on Sliplane with basic auth. Basic auth is a simple way to secure your apps by adding a username and password to your app that will be prompted by the browser. To achieve this, we will deploy your app that you want to secure with basic auth as a private service and then we will deploy a basic auth proxy service that will act as a reverse proxy and add basic auth to your app. If you prefer just seeing the code and figuring out the rest yourself, you can find the complete code for this tutorial on [GitHub](https://github.com/sliplane/basic-auth-proxy). ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * A Sliplane account * A **private** HTTP service that you want to secure with basic auth * 10 minutes of your time! ## Setup [Section titled “Setup”](#setup) 1. Fork the [basic-auth-proxy](https://github.com/sliplane/basic-auth-proxy) repository 2. Give Sliplane access to your forked repository 3. Set the healthcheck to /health 4. Set the following environment variables: ```plaintext PORT=8080 HTTP_BASIC_AUTH_USER=yourusername HTTP_BASIC_AUTH_PASSWORD=yourpassword PRIVATE_WEBSITE_URL=the-url-of-your-private-service, including protocol and port ``` You can find the private website URL by clicking on the service in the Sliplane dashboard and looking at the URL field. 5. Deploy the service  You can now access your private service by visiting the URL of the service in the Sliplane dashboard! *** If you have any questions or need assistance in setting up your basic auth proxy, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=Basic%20Auth). We’re always here to help! # How to use Cloudflare with Sliplane > This guide explains how to connect your domain from Cloudflare to a service running on Sliplane. This guide explains how to connect your domain from Cloudflare to a service running on Sliplane. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * You must already have a domain added to [Cloudflare](https://www.cloudflare.com/) * You must have a Sliplane service running *** ## Step 1: Add Your Domain in Sliplane [Section titled “Step 1: Add Your Domain in Sliplane”](#step-1-add-your-domain-in-sliplane) 1. Go to your **service dashboard** in Sliplane. 2. Click the **Domains** tab.  3. Click **Add Domain**. 4. Enter your full domain (e.g. `example.com` or `app.example.com`) and click **Add**. 5. Sliplane will show you the required DNS record: * **Prefer CNAME**: Use CNAME if possible, because it automatically tracks Sliplane IP changes.  *** ## Step 2: Add DNS Record in Cloudflare [Section titled “Step 2: Add DNS Record in Cloudflare”](#step-2-add-dns-record-in-cloudflare) 1. Log in to [Cloudflare Dashboard](https://dash.cloudflare.com/). 2. Select your domain. 3. Go to the **DNS** tab. 4. Click **Add Record**: * **Type**: CNAME * **Name**: `@` for root or your subdomain (e.g. `app`) * **Target**: Use the CNAME value from Sliplane 5. Set **Proxy status** to **DNS only** (not proxied).\ → ⚠️ *Disable the orange cloud icon at first.* *** ## Step 3: Wait for Domain Verification [Section titled “Step 3: Wait for Domain Verification”](#step-3-wait-for-domain-verification) * Sliplane will verify the domain within \~15 minutes. * Once verified, you can **enable the Cloudflare proxy** by toggling the orange cloud back on. *** ## Step 4: Enable Full Strict SSL [Section titled “Step 4: Enable Full Strict SSL”](#step-4-enable-full-strict-ssl) 1. In Cloudflare, go to your domain. 2. Click **SSL/TLS** in the left menu. 3. Set the **SSL mode** to **Full (Strict)**. This ensures encrypted connections both: * Between browser and Cloudflare * Between Cloudflare and Sliplane  *** ## Optional: Geo-blocking Exception [Section titled “Optional: Geo-blocking Exception”](#optional-geo-blocking-exception) If you’re using geo-blocking or other firewall features: * **Exclude the route `https://{your-domain}/.well-known/acme-challenge/**123**`**\ → This route is used for SSL certificate renewals. Blocking it will cause renewals to fail. *** ## Done [Section titled “Done”](#done) Your Sliplane service should now be accessible via your Cloudflare-managed domain, with secure HTTPS and CDN-level features. # File Browser > Browse files in your volumes In this tutorial we will take a look at how you can upload and download files to your Sliplane volumes. This tutorial assumes that you already have a service with an attached volume deployed. If you don’t have one, you can follow the [Deploying a Service](/services/deploying-a-service) tutorial to get started. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * A Sliplane account * A service with an attached volume * 10 minutes of your time! ## Setup [Section titled “Setup”](#setup) To access our volume we are going to create a new service that will provide us a beautiful web interface to browse the files in our volume. For that we are going to use the [File Browser](https://github.com/filebrowser/filebrowser) project. To deploy it, we simply need to create a new service on the same server as your volume. Select the Registry option and search for `filebrowser` in the docker hub registry, or copy this url `docker.io/filebrowser/filebrowser:latest` into the image field. The only other thing you need to do is attach the volume you want to browse at `/srv` in the volume section. Below you can see what the deployment should look like.  After the service is deployed you can access the file browser by visiting the URL of the service in the Sliplane dashboard.  The default credentials are `admin` for the username and the password can be found in the logs after the first setup. You should change these after logging in for the first time, you can do this by clicking on the `Settings` gear icon in the top right corner and then clicking on `User Management`. *After your done with doing your thing you can delete the service, we won’t need it anymore!* *** If you have any questions or need assistance in setting up your file browser, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=File%20Browser). We’re always here to help! # Github Actions Integration > Learn how to integrate Github Actions with Sliplane This guide shows how to automatically deploy your application to Sliplane using Github Actions. At the end of this guide, you will be able to push to your repository, build your Docker image, push it to Github Container Registry, and deploy it to Sliplane. All automatically. ## Setup Steps [Section titled “Setup Steps”](#setup-steps) 1. **Configure Github Repository Settings** * Go to your repository’s Settings > Actions > General * Under “Workflow permissions”, enable “Read and write permissions”  2. **Create Github Personal Access Token** * Go to [Github Token Settings](https://github.com/settings/tokens/new) * Create a classic token with `read:packages` permission  3. **Add Registry Credentials to Sliplane** * Navigate to [Registry Credentials](https://sliplane.io/app/team/registryCredentials) * Select “ghcr.io” as registry * Enter your Github username and PAT token  4. **Configure Github Secrets** * In your repository settings, add a new secret named `DEPLOY_SECRET` * Copy the `dhs_` part from your Sliplane deploy hook URL (see last screenshot)  5. **Add Workflow File** Create `.github/workflows/deploy.yml` with the following content: ```yaml name: Docker Build and Sliplane Deploy on: push: branches: - main workflow_dispatch: jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Login to GitHub Container Registry uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Build and push Docker image uses: docker/build-push-action@v5 with: context: . push: true tags: | ghcr.io/your-name/your-repo:latest ghcr.io/your-name/your-repo:${{ github.sha }} - name: Deploy to Sliplane run: | curl "https://api.sliplane.io/deploy/your-service-id/${{ secrets.DEPLOY_SECRET }}?tag=${{ github.sha }}" ``` 6. **Update Workflow Configuration** In the workflow file above: * Replace `your-name` with your Github username * Replace `your-repo` with your repository name * Replace `your-service-id` with your Sliplane service ID (found in service dashboard)  Now when you push to the main branch, Github Actions will automatically build your Docker image and deploy it to Sliplane. # SSH Tunneling > Learn how to set up SSH tunneling to access private services ## SSH Access Methods in Sliplane [Section titled “SSH Access Methods in Sliplane”](#ssh-access-methods-in-sliplane) Sliplane offers two ways to connect to services via SSH: [Direct SSH to Container ](/services/ssh)Execute commands directly in your container. Great for debugging and admin tasks. Supports SCP and rsync if installed in the container. [SSH Tunneling ](/guides/ssh#ssh-tunnel-setup)Access private services in the same Docker network. Supports full SSH functionality including SCP, rsync, and port forwarding. ## SSH Tunnel Setup [Section titled “SSH Tunnel Setup”](#ssh-tunnel-setup) SSH tunneling is ideal when you need to: * Access private databases from outside the network * Use SCP or rsync to transfer files * Set up port forwarding to local development environment * Connect to multiple private services through a single entry point Deploy the SSH Tunnel preset. You can keep all the default settings:  After deploying the service (should take <15 seconds), you will find the port, host, and password in the service details. Copy the host and port and use the following command to connect to your service: ```bash ssh root@.sliplane.app -p 2222 ``` It will ask for the password you set in your environment variables. ## Using SSH Keys Instead of Password [Section titled “Using SSH Keys Instead of Password”](#using-ssh-keys-instead-of-password) To use SSH key authentication instead of password: 1. **Copy your existing SSH public key** (usually found at `~/.ssh/id_rsa.pub`): ```bash cat ~/.ssh/id_rsa.pub ``` 2. **Add the public key to your SSH tunnel service**: * Navigate to your SSH tunnel service in Sliplane * Go to the “Environment Variables” section * Add a new environment variable: * Key: `SSH_AUTHORIZED_KEYS` * Value: Paste your entire public SSH key 3. **Update authentication method**: * Remove the `ROOT_PASSWORD` environment variable if you only want key-based authentication * Or keep both for dual authentication methods 4. **Restart the service** to apply changes 5. **Connect using your SSH key**: ```bash ssh root@.sliplane.app -p 2222 ``` No password prompt will appear if your key is correctly configured. Note The SSH tunnel service requires either `ROOT_PASSWORD` or `SSH_AUTHORIZED_KEYS` environment variable to be set. Without at least one of these, the service will fail to start. For implementation details, see the [Github Repository](https://github.com/sliplane/docker-ssh). Once you are connected, you are in the same network as all your private services. You will be able to reach them via their service name. You can also tunnel other private services to localhost by using port forwarding. ```bash ssh -L 8080:: root@.sliplane.app -p 2222 ``` Here port `8080` on your local machine will be forwarded to port `your-app-port` on your service. The ports as well as the host are configurable and depend on the service you want to reach. If you want to have console access to your service you will have to install a SSH server on the service you want to access. To learn how to do that, check out the [SSH Server](https://github.com/sliplane/docker-ssh) repository. # Redirects > Learn how to set up a redirect service for www subdomains If you want to redirect `www.example.com` to `example.com` you need a separate redirect service for example . This guide shows you how to set it up using a simple NGINX-based image. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * A Sliplane account * A service with a custom domain setup (example.com in this case) ## Setting up the Redirect Service [Section titled “Setting up the Redirect Service”](#setting-up-the-redirect-service) Create a new `Dockerfile`: ```dockerfile FROM nginx:alpine COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] ``` Create an `nginx.conf` file: ```nginx server { listen 80; server_name www.example.com; location / { return 301 https://example.com$request_uri; } } ``` Replace `www.example.com` and `example.com` with your domains. Push both files to any Github repository. Deploy the service to Sliplane: * Create a new service * Set PORT environment variable to 80 * Set the custom domain to your www domain (e.g., `www.example.com`) Now, when users visit your www domain, they will be automatically redirected to your apex domain while preserving the path and query parameters. # Getting Help > Learn how to get started with Sliplane teams. We are here to create the best possible hosting platform so please help us by leaving your feedback. In case you run into issues, you have any questions, you need any help with deploying your servers or you need a new feature, please do not hesitate to [contact us](mailto:support@sliplane.io). You can also reach us via the chat widget at the bottom right corner of our app. # Getting Started > Learn how to sign up for Sliplane and the different ways to manage your infrastructure. ## Create an Account [Section titled “Create an Account”](#create-an-account) Note Sliplane requires a GitHub account for authentication. You can create a GitHub account [over here](https://github.com/signup) if you don’t already have one. To get started: 1. Go to [sliplane.io](https://sliplane.io) and click “Dashboard” in the navbar 2. Click on “Login with GitHub” to log into the Sliplane Dashboard. If you don’t have a Sliplane account yet, a new account will be created automatically on first login. ## Quickstart: Deploying your first Service [Section titled “Quickstart: Deploying your first Service”](#quickstart--deploying-your-first-service) ### Deploy a Preset [Section titled “Deploy a Preset”](#deploy-a-preset) Sliplane provides a [catalogue of popular preconfigured services](https://sliplane.io/apps) that can be deployed with a single click: 1. Login to your Sliplane account 2. [Create a new project](/projects/getting-started) or select an existing one from the Dashboard 3. Inside the project click “Deploy service” 4. Select the server, where the service should be deployed to or create a new one in a location of your choice 5. Click “Add service”, a drawer opens from the right with a list of presets 6. Choose a preset that you want to deploy, you can review and update the settings if necessary. Once you are happy with the configuration click “Add service” in the top right and then click “Deploy” Your service will be up and running shortly, and depending on the preset, you will be hooked up with a public URL that you can use in order to access your service. ### Deploy prebuild containers from a Registry [Section titled “Deploy prebuild containers from a Registry”](#deploy-prebuild-containers-from-a-registry) If you want to deploy a prebuild container from a private or public registry, you can follow this quickstart guide to get started: 1. Login to your Sliplane account 2. [Create a new project](/projects/getting-started) or select an existing one from the Dashboard 3. Inside the project click “Deploy service” 4. Select the server, where the service should be deployed to or create a new one in a location of your choice 5. Click “Add service”, a drawer opens from the right and choose “Registry” 6. Add the necessary configuration, click “Add service” in the top right and then click “Deploy” More details on deploying from a registry can be found [here](/services/deploying-a-service#deploy-from-a-registry). ### Deploy custom Code from GitHub [Section titled “Deploy custom Code from GitHub”](#deploy-custom-code-from-github) Sliplane allows you to deploy custom code directly from a GitHub repository. It picks up new commits automatically then builds and ships new code: 1. Login to your Sliplane account 2. [Create a new project](/projects/getting-started) or select an existing one from the Dashboard 3. Inside the project click “Deploy service” 4. Select the server, where the service should be deployed to or create a new one in a location of your choice 5. Click “Add service”, a drawer opens from the right and choose “Repository” 6. Add the necessary configuration, click “Add service” in the top right and then click “Deploy” Note: A Dockerfile is optional. If your repository contains one, Sliplane will use it to build your image. If not, Sliplane will automatically detect your application’s stack and build it for you using [Railpack](https://railpack.com/) — no extra configuration required. If you want full control over the build, you can add a Dockerfile to your repository. You can use the Docker CLI to set one up automatically with `docker init`. You can find examples on how to create Dockerfiles for popular frameworks on our blog: * [How to Dockerize and Deploy Express.js APIs](https://sliplane.io/blog/how-to-dockerize-and-deploy-express-js-apis) * [How to Dockerize and Deploy Fastify APIs](https://sliplane.io/blog/how-to-dockerize-and-deploy-fastify-apis) * [How to Dockerize and Deploy Astro](https://sliplane.io/blog/how-to-dockerize-and-deploy-astro) * [How to Dockerize Vite](https://sliplane.io/blog/how-to-dockerize-vite) * [How to Dockerize Remix Apps](https://sliplane.io/blog/how-to-dockerize-remix-apps) * [How to Dockerize a Bun App](https://sliplane.io/blog/how-to-dockerize-a-bun-app) * [Dockerfile reference](https://docs.docker.com/reference/dockerfile/) (Docker docs) Note Docker Compose files are not fully supported yet. We have a parser in the UI that allows you to paste the contents of your Docker Compose file, and Sliplane will parse the configuration into Sliplane constructs. Note that only a subset of Docker Compose features are supported. More details on deploying from GitHub can be found [here](/services/deploying-a-service#deploy-from-github). ### Guides to deploy popular Software [Section titled “Guides to deploy popular Software”](#guides-to-deploy-popular-software) * [n8n](https://sliplane.io/blog/self-hosting-n8n-the-easy-way) - Workflow automation * [Open WebUI + Ollama](https://sliplane.io/blog/self-hosting-openwebui-ollama-the-easy-way) - Local LLMs * [Grafana](https://sliplane.io/blog/self-hosting-grafana-the-easy-way) - Monitoring & dashboards * [Nextcloud](https://sliplane.io/blog/self-hosting-nextcloud-the-easy-way) - Cloud storage * [Activepieces](https://sliplane.io/blog/self-hosting-activepieces-the-easy-way) - Workflow automation * [Paperless-ngx](https://sliplane.io/blog/self-hosting-paperless-ngx-the-easy-way) - Document management * [Qdrant](https://sliplane.io/blog/self-hosting-qdrant-the-easy-way) - Vector database * [OpenCloud](https://sliplane.io/blog/self-hosting-opencloud-the-easy-way) - Cloud collaboration * [Kimai](https://sliplane.io/blog/self-hosting-kimai-the-easy-way) - Time tracking * [Ghost](https://sliplane.io/blog/deploy-ghost-with-docker-on-sliplane) - Blogging platform * [Uptime Kuma](https://sliplane.io/blog/how-to-host-uptime-kuma) - Uptime monitoring More tutorials can be found in the [tutorials section](https://sliplane.io/categories/tutorials) on our blog. ### Guides for Security, Data & Backups [Section titled “Guides for Security, Data & Backups”](#guides-for-security-data--backups) * [Private Networking](/private-networking/overview) - Restrict access to services by configuring private networks * [Access Control](/services/access-control) - Restrict access to TCP/UDP services by IP * [Basic Auth](/guides/basic-auth) - Add authentication to HTTP services * [SSH Access](/services/ssh) - Connect to your containers via SSH * [Volumes & Backups](/servers/volumes) - Persistent storage with automated daily backups * [Setup TLS for PostgreSQL in Docker](https://sliplane.io/blog/setup-tls-for-postgresql-in-docker) (blog) * [Backup & Restore Postgres via SSH Tunnel](https://sliplane.io/blog/backup-and-restore-postgres-via-ssh-tunnel) (blog) * [Best Practices for Postgres in Docker](https://sliplane.io/blog/best-practices-for-postgres-in-docker) (blog) ## How to Interact with Sliplane [Section titled “How to Interact with Sliplane”](#how-to-interact-with-sliplane) ### Dashboard [Section titled “Dashboard”](#dashboard) The [Sliplane Dashboard](https://sliplane.io/app) is the primary user interface to manage your infrastructure. Use it to create servers, deploy and configure services, manage team members, set up billing, and everything else covered in these docs. ### API [Section titled “API”](#api) The [Sliplane API](https://ctrl.sliplane.io) lets you manage resources programmatically. Use it to automate deployments, integrate with CI/CD pipelines, or build custom tooling on top of Sliplane. Create an [API key](/teams/api-keys) in your team settings to get started. ### MCP [Section titled “MCP”](#mcp) The [Sliplane MCP server](/mcp/getting-started) connects Sliplane to AI coding tools like Claude Code, Cursor, and VS Code. Manage deployments, check status, and trigger operations directly from your editor. You can find more tutorials in the [AI coding section](https://sliplane.io/categories/mcp) on our blog. ## Sliplane Concepts [Section titled “Sliplane Concepts”](#sliplane-concepts) ### Teams [Section titled “Teams”](#teams) [Teams](/teams/getting-started) are used to group servers, projects and services. You can create as many teams as you like, and each team has its own subscription and billing. You can also use teams for client projects and do a complete handover. ### Projects [Section titled “Projects”](#projects) Services are organized in projects and before you can deploy your first service, you need to [create a new project](/projects/getting-started). This is purely an organizational layer and you can decide how to group your services. For example, you can create one project for all your internal tools, one project per app, one project for your background jobs, etc. ### Servers [Section titled “Servers”](#servers) [Servers](/servers/create-a-server) host your services and you can run as many services on a single server as its resources allow, without extra charges. You are billed for every server that runs in your account. More information can be found in the [billing docs](/teams/billing). ### Services [Section titled “Services”](#services) A [service](/services/deploying-a-service) in Sliplane is your application running on a server, along with its configuration. Services give you the flexibility to run almost any software, from databases and AI tools to custom frontends and backends. You can ship your own custom code straight from GitHub — with or without a Dockerfile, since Sliplane can build your app for you with [Railpack](https://railpack.com/) — or deploy prebuilt images from public or private container registries. ### Object Storage [Section titled “Object Storage”](#object-storage) [Object Storage](/object-storage/getting-started) gives your team S3-compatible buckets for files, uploads, backups, and generated assets — anything that doesn’t belong on a server volume. Use it with the AWS CLI or any S3-compatible SDK. # Getting Started with the Sliplane MCP server > Connect AI coding tools to Sliplane with MCP using OAuth or an API key. Connect your AI coding tools to Sliplane using the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/). The Sliplane MCP server is a hosted, remote MCP server available at: ```plaintext https://mcp.sliplane.io ``` Danger WARNING: You can execute destructive commands against your deployments. Use with caution and always double check your commands before executing them. ## What is the Sliplane MCP server? [Section titled “What is the Sliplane MCP server?”](#what-is-the-sliplane-mcp-server) The Sliplane MCP server gives compatible AI clients access to the functionality of the [Sliplane API](https://ctrl.sliplane.io). It uses Streamable HTTP and supports OAuth, so compatible clients can open the Sliplane authorization flow and receive a scoped API token without requiring you to copy an API key into their configuration. You can use it to: * Manage deployments * Access project information * Monitor application status * Execute deployment operations ## Authentication [Section titled “Authentication”](#authentication) OAuth is the recommended authentication method. When your MCP client connects, it opens Sliplane in your browser so you can sign in and authorize access. Use these OAuth settings if your client asks for them: * **Client ID**: `sliplane-mcp` * **Scope**: `full` * **Client secret**: None API keys remain supported for clients that do not support OAuth. You can create an [API key](/teams/api-keys) in your Sliplane team settings and send it as a bearer token. ## Setup [Section titled “Setup”](#setup) Choose your MCP client below. The hosted server requires no local installation or self-hosting. ### Claude Code [Section titled “Claude Code”](#claude-code) * OAuth Add the Sliplane MCP server with its OAuth client ID: ```bash claude mcp add --transport http \ --client-id sliplane-mcp \ sliplane https://mcp.sliplane.io ``` Start Claude Code, enter `/mcp`, and complete the browser authorization flow. * API key Create an [API key](/teams/api-keys), then send it as a bearer token: ```bash claude mcp add --transport http \ -H "Authorization: Bearer yourapikeyhere" \ sliplane https://mcp.sliplane.io ``` ### Codex [Section titled “Codex”](#codex) * OAuth Add the Sliplane MCP server with OAuth: ```bash codex mcp add sliplane \ --url https://mcp.sliplane.io \ --oauth-client-id sliplane-mcp ``` Complete the browser authorization flow when Codex connects to the server. * API key Create an [API key](/teams/api-keys), then send it as `--bearer-token-env-var`: ```bash export SLIPLANE_API_KEY=yourapikeyhere codex mcp add sliplane \ --url https://mcp.sliplane.io \ --bearer-token-env-var SLIPLANE_API_KEY ``` ### Cursor [Section titled “Cursor”](#cursor) Add one of the following configurations to your project-specific or global `.cursor/mcp.json` file: * OAuth ```json { "mcpServers": { "sliplane": { "url": "https://mcp.sliplane.io", "auth": { "CLIENT_ID": "sliplane-mcp", "scopes": ["full"] } } } } ``` When Cursor connects, complete the OAuth authorization flow. * API key ```json { "mcpServers": { "sliplane": { "url": "https://mcp.sliplane.io", "headers": { "Authorization": "Bearer yourapikeyhere" } } } } ``` ### opencode [Section titled “opencode”](#opencode) * OAuth Run the interactive setup: ```bash opencode mcp add ``` Enter the following values when prompted: ```text ┌ Add MCP server │ ◇ Enter MCP server name │ sliplane │ ◇ Select MCP server type │ Remote │ ◇ Enter MCP server URL │ https://mcp.sliplane.io │ ◇ Does this server require OAuth authentication? │ Yes │ ◇ Do you have a pre-registered client ID? │ Yes │ ◇ Enter client ID │ sliplane-mcp │ ◇ Do you have a client secret? │ No ``` Then authenticate with Sliplane: ```bash opencode mcp auth sliplane ``` * API key Create an [API key](/teams/api-keys), then: ```bash opencode mcp add sliplane \ --url https://mcp.sliplane.io \ --header "Authorization=Bearer yourapikeyhere" ``` ### Visual Studio Code [Section titled “Visual Studio Code”](#visual-studio-code) VS Code can connect using an API key. Create `.vscode/mcp.json` in your repository: ```json { "servers": { "sliplane": { "type": "http", "url": "https://mcp.sliplane.io", "headers": { "Authorization": "Bearer yourapikeyhere" } } } } ``` ## Other MCP clients [Section titled “Other MCP clients”](#other-mcp-clients) For clients not listed above, use the following connection settings: * **URL**: `https://mcp.sliplane.io` * **Transport**: Streamable HTTP * **OAuth client ID**: `sliplane-mcp` * **OAuth scope**: `full` * **OAuth client secret**: None Use the authentication settings that match your client: * OAuth ```text OAuth client ID: sliplane-mcp OAuth scope: full OAuth client secret: none ``` * API key ```text Authorization: Bearer yourapikeyhere ``` # GitHub integration > Learn how to integrate your GitHub account with your Sliplane account. In order to deploy new services directly from GitHub, you need to allow Sliplane to have access to the repository that you want to deploy. This can be done by clicking on the account menu in the top navbar of the app and selecting ***Repository Access*** from the dropdown. You will be redirected to GitHub to manage Sliplanes permissions. After selecting the repository, you will be redirected back to Sliplane, where you should be able to see the repository in the dropdown while creating a new service. This can take a little bit, so If you can’t see the repository, try refreshing the list a few times. *** ## What is the Sliplane GitHub App doing? [Section titled “What is the Sliplane GitHub App doing?”](#what-is-the-sliplane-github-app-doing) The Sliplane GitHub app has two main functions: 1. To log in with Sliplane we use GitHub login. This means that your login is both faster and more secure. 2. To deploy your code, we need to be able to read your code and metadata, and in order to deploy new versions we need to be able to create webhooks for push events on your selected repository. Sliplane only has read access to the repositories you explicitly select, and we only create webhooks for the repositories you create services for. The webhooks are only used to trigger deployments, and are deleted when you delete the service. ### What permissions does the Sliplane GitHub App need? [Section titled “What permissions does the Sliplane GitHub App need?”](#what-permissions-does-the-sliplane-github-app-need) If you first sign up with Sliplane you will see that the GitHub app needs the following permissions: #### Read access to code and metadata [Section titled “Read access to code and metadata”](#read-access-to-code-and-metadata) This means that we can see the code of the repositories you shared with us, which is required so that we can clone the repository to your server. We also need to be able to read the metadata of the repository, such as the default branch or the used programming language. #### Read and write access to repository hooks [Section titled “Read and write access to repository hooks”](#read-and-write-access-to-repository-hooks) This means that we can create webhooks for the repositories you shared with us, which is required so that we can trigger deployments when you push new code to your repository. Everytime you push code to your repository we get a message. If the message is a push event on your selected branch, we trigger a new deployent. We only create webhooks for the repositories you create services for, and we delete the webhooks when you delete the service. #### Read access to organization membership [Section titled “Read access to organization membership”](#read-access-to-organization-membership) This means that we can see who is collaborating on the repositories you shared with us. This is required so that we check that you have admin access to the repository you want to deploy. The admin access is required so that we can create webhooks for the repository. We do not care or store any information about who is collaborating on your repositories. *** If you have any questions or need assistance, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=GitHub). We’re always here to help! # Automatic SSL/HTTPS > Learn how automatic SSL/HTTPS works at Sliplane. By default, your services are assigned free subdomains on sliplane.app with automatic SSL/HTTPS. Both the first certificate and all renewals are completely free of charge and done automatically, even for your own domains. To find out how to use SSL/HTTPS for custom domains, see [Custom domains](/services/custom-domains). *** ## How does it work? [Section titled “How does it work?”](#how-does-it-work) We use [Let’s Encrypt](https://letsencrypt.org/) to automatically generate SSL certificates for your service. Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/). This means that your application does not need to handle SSL certificates or HTTPS at all. It can simply listen on the port provided by the environment variable **PORT** and Sliplane will take care of the rest. This also means that you will never have to worry about renewing your SSL certificate! *** If you have any questions or need help, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=SSL). We’re always here to help! # Buckets and Access Keys > Learn how buckets, access keys, versioning, object locking, and deletion work in Sliplane Object Storage. Buckets are the top-level containers for objects in Sliplane Object Storage. Access keys are credentials that allow applications and S3 clients to access one bucket. ## Buckets [Section titled “Buckets”](#buckets) Buckets belong to your team. Any team member with access to Object Storage can manage the team’s buckets in the Sliplane dashboard. A bucket has a globally unique name, a region, an endpoint, and a status. You can store any number of objects in a bucket, as long as your team stays within the documented limits. ## Versioning [Section titled “Versioning”](#versioning) Versioning keeps previous versions of objects when they are overwritten or deleted. Enable versioning when you want protection against accidental overwrites or deletes. Keep in mind that stored versions count toward your total Object Storage usage. ## Object locking [Section titled “Object locking”](#object-locking) Object locking prevents objects from being deleted or overwritten for a retention period. Object locking also enables versioning. Use it for workloads that need stronger protection against accidental or unwanted changes. ## Access keys [Section titled “Access keys”](#access-keys) Each access key is scoped to exactly one bucket. An access key can: * read and write objects in its bucket * list objects in its bucket * list buckets and see whether other buckets exist in the same team An access key cannot read, write, or delete objects in any other bucket. Caution Secret access keys are only returned once, when the key is created. If you lose a secret access key, delete the key and create a new one. ## Deleting access keys [Section titled “Deleting access keys”](#deleting-access-keys) Delete an access key when it is no longer used or if you think it may have been exposed. Deleting an access key immediately prevents clients from using that key to access the bucket. ## Deleting buckets [Section titled “Deleting buckets”](#deleting-buckets) When you delete a bucket, Sliplane schedules it for deletion with a 24-hour grace period. After the grace period, the bucket and its access keys are removed. Caution Deleting a bucket also deletes the objects stored in it. Make sure you have copied any data you still need before deleting a bucket. ## API [Section titled “API”](#api) The Sliplane API supports listing, creating, and deleting buckets, as well as listing, creating, and deleting bucket access keys. Open the [API documentation](https://ctrl.sliplane.io/#tag/buckets) for the full request and response schema. # Object Storage > Store files, uploads, backups, and other objects in S3-compatible buckets managed through Sliplane. Sliplane Object Storage gives your team S3-compatible buckets for files, uploads, backups, generated assets, and other data that does not belong on a server volume. ## How it works [Section titled “How it works”](#how-it-works) Object Storage is managed at the team level. Buckets are not tied to a specific project, server, or service. From the Sliplane dashboard, open **Object Storage** in the main navigation. From there you can create buckets, view existing buckets, and manage access keys for each bucket. Each bucket has: * a globally unique bucket name * a region * an S3-compatible endpoint * optional versioning * optional object locking * one or more access keys ## Regions [Section titled “Regions”](#regions) Object Storage is currently available in these regions: | Region ID | Region | City | | --------- | ------- | --------- | | `ger` | Germany | Frankfurt | | `us-east` | US East | New York | Choose the region closest to your application or users. ## Create a bucket [Section titled “Create a bucket”](#create-a-bucket) In the dashboard, go to **Object Storage** and click **Create Bucket**. Choose a bucket name, region, and whether you want to enable versioning or object locking. Bucket names must follow S3 naming rules: * 3 to 63 characters * lowercase letters, numbers, dots, and hyphens * must start and end with a letter or number * must be globally unique ## Create an access key [Section titled “Create an access key”](#create-an-access-key) Open a bucket and create an access key for it. Access keys are scoped to exactly one bucket and have full read/write access to that bucket. They can list buckets and see whether other buckets exist in the same team, but they cannot access objects in other buckets. Caution The secret access key is shown only once when the key is created. Store it securely before closing the dialog. ## Use the bucket [Section titled “Use the bucket”](#use-the-bucket) Use the bucket endpoint, bucket name, access key ID, and secret access key with any S3-compatible client. ### Configure your environment [Section titled “Configure your environment”](#configure-your-environment) The AWS CLI and AWS SDKs read credentials and endpoint configuration automatically from either **environment variables** or a named **profile**. You can also pass these values explicitly in your code as function parameters, but using environment variables or a profile is more portable and works across all clients. You can find the **endpoint URL** in the Sliplane dashboard where your bucket is located. Many clients call this a custom endpoint, endpoint URL, or S3-compatible endpoint. #### Option 1: Environment variables [Section titled “Option 1: Environment variables”](#option-1-environment-variables) * Linux or macOS ```bash export AWS_ACCESS_KEY_ID="your_access_key_id" export AWS_SECRET_ACCESS_KEY="your_secret_access_key" export AWS_ENDPOINT_URL="https://your_bucket_endpoint" export AWS_REGION="auto" ``` * Windows Command Prompt ```bat setx AWS_ACCESS_KEY_ID your_access_key_id setx AWS_SECRET_ACCESS_KEY your_secret_access_key setx AWS_ENDPOINT_URL https://your_bucket_endpoint setx AWS_REGION auto ``` * PowerShell ```powershell $Env:AWS_ACCESS_KEY_ID="your_access_key_id" $Env:AWS_SECRET_ACCESS_KEY="your_secret_access_key" $Env:AWS_ENDPOINT_URL="https://your_bucket_endpoint" $Env:AWS_REGION="auto" ``` That’s it. Now, you’re good to go. #### Option 2: AWS profile [Section titled “Option 2: AWS profile”](#option-2-aws-profile) Add a named profile to your AWS configuration files. On Linux and macOS these live in `~/.aws/`; on Windows they live in `%USERPROFILE%\.aws\`. `~/.aws/credentials`: ```ini [sliplane] aws_access_key_id = your_access_key_id aws_secret_access_key = your_secret_access_key ``` `~/.aws/config`: ```ini [profile sliplane] endpoint_url = https://your_bucket_endpoint region = auto ``` Then export the profile to your environment: * Linux or macOS ```bash export AWS_PROFILE=sliplane ``` * Windows Command Prompt ```bat setx AWS_PROFILE sliplane ``` * PowerShell ```powershell $Env:AWS_PROFILE="sliplane" ``` Note Endpoint configuration settings are located in multiple places, such as the system or user environment variables, local AWS configuration files, or explicitly declared on the command line as a parameter. For more details, please see [S3 endpoint configuration and settings precedence](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-endpoints.html#endpoints-precedence). ### Quick starts [Section titled “Quick starts”](#quick-starts) With the environment variables in place, you can start managing buckets and objects from the AWS CLI or any AWS SDK. Here are a few examples to get you started. * AWS CLI ```bash # List buckets aws s3 ls # Upload a file aws s3 cp ./hello.txt s3://my-bucket/ # Download a file aws s3 cp s3://my-bucket/hello.txt ./hello.txt ``` * JavaScript ```javascript import { S3Client, ListBucketsCommand, PutObjectCommand, ListObjectsV2Command, GetObjectCommand, } from "@aws-sdk/client-s3" import { getSignedUrl } from "@aws-sdk/s3-request-presigner" const s3 = new S3Client({}) const BUCKET_NAME = "my-bucket" // List buckets const { Buckets } = await s3.send(new ListBucketsCommand({})) console.log(Buckets) // Upload a file await s3.send( new PutObjectCommand({ Bucket: BUCKET_NAME, Key: "hello.txt", Body: "Hello, Sliplane!", }), ) // List objects in the bucket const list = await s3.send( new ListObjectsV2Command({ Bucket: BUCKET_NAME }), ) console.log(list.Contents) // Get a presigned URL for the object const url = await getSignedUrl( s3, new GetObjectCommand({ Bucket: BUCKET_NAME, Key: "hello.txt", }), { expiresIn: 120 }, ) console.log(url) ``` * Python ```python import boto3 s3 = boto3.client("s3") # List buckets for bucket in s3.list_buckets()["Buckets"]: print(bucket["Name"]) # Upload a file s3.upload_file("./hello.txt", "my-bucket", "hello.txt") ``` * Go ```go package main import ( "context" "fmt" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/service/s3" ) func main() { ctx := context.Background() sdkConfig, _ := config.LoadDefaultConfig(ctx) s3Client := s3.NewFromConfig(sdkConfig) result, _ := s3Client.ListBuckets(ctx, &s3.ListBucketsInput{}) for _, b := range result.Buckets { fmt.Println(*b.Name) } } ``` * Java ```java import software.amazon.awssdk.services.s3.S3Client; public class HelloS3 { public static void main(String[] args) { S3Client s3 = S3Client.builder().build(); s3.listBuckets().buckets().forEach(b -> System.out.println(b.name())); } } ``` ### AWS CLI and SDK guides [Section titled “AWS CLI and SDK guides”](#aws-cli-and-sdk-guides) The following table lists the official AWS CLI and SDK guides for popular languages and frameworks. | Language or framework | Library | Documentation | | ----------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | CLI | AWS CLI | [Custom endpoints in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-endpoints.html) | | JavaScript / TypeScript | AWS SDK for JavaScript v3, `@aws-sdk/client-s3` | [Amazon S3 examples using SDK for JavaScript v3](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/javascript_s3_code_examples.html) | | Python | boto3 | [boto3 S3 reference](https://docs.aws.amazon.com/boto3/latest/reference/services/s3.html) | | Go | AWS SDK for Go v2, `service/s3` | [Amazon S3 examples using SDK for Go v2](https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/go_s3_code_examples.html) | | Java | AWS SDK for Java 2.x | [Work with Amazon S3](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3.html) | | .NET | AWS SDK for .NET, `AWSSDK.S3` | [Using Amazon S3 with the AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/s3-apis-intro.html) | | PHP | AWS SDK for PHP | [AWS SDK for PHP S3Client](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.S3.S3Client.html) | | Ruby | AWS SDK for Ruby, `aws-sdk-s3` | [AWS SDK for Ruby S3 client](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/Client.html) | | Rust | AWS SDK for Rust, `aws-sdk-s3` | [Amazon S3 examples using SDK for Rust](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/rust_s3_code_examples.html) | | Kotlin | AWS SDK for Kotlin | [Work with Amazon S3 using the AWS SDK for Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin/latest/developer-guide/use-services-s3.html) | | Laravel | Laravel filesystem S3 driver | [Laravel S3 driver configuration](https://laravel.com/docs/filesystem#s3-driver-configuration) | | Rails | Active Storage S3 service | [Rails Active Storage S3 service](https://guides.rubyonrails.org/active_storage_overview.html#s3-service-amazon-s3-and-s3-compatible-apis) | | Django | django-storages S3 backend | [django-storages Amazon S3 backend](https://django-storages.readthedocs.io/en/stable/backends/amazon-S3.html) | ## API [Section titled “API”](#api) You can also manage buckets and access keys through the [Sliplane API](https://ctrl.sliplane.io/#tag/buckets). ## Infrastructure provider [Section titled “Infrastructure provider”](#infrastructure-provider) Object Storage is provided in partnership with [ImpossibleCloud GmbH](https://www.impossiblecloud.com/), a German company with over 140PB of capacity that is also ISO 27001 certified. You create and manage buckets and access keys in Sliplane, and Sliplane handles billing for your team. # Limits > Learn about bucket, object, and S3 API limits for Sliplane Object Storage. ## Bucket limits [Section titled “Bucket limits”](#bucket-limits) You can keep any number of objects in a single bucket. Each team can have up to **100 buckets**. More available on request. ## Object name restrictions [Section titled “Object name restrictions”](#object-name-restrictions) Object names are primarily limited by the local operating system and filesystem used by your application or tooling. Some operating systems, such as Windows, restrict certain characters in file names, including: ```txt ; ^ / * | " & ``` This list may not be exhaustive. Check the documentation for your operating system or filesystem if your application depends on specific object names. Object Storage currently does not support: * object names that start with a forward slash * empty path segments ## S3 API limits [Section titled “S3 API limits”](#s3-api-limits) | Limit | Value | | ------------------------------------------------ | --------------- | | Maximum object size | 50 TiB | | Minimum object size | 0 B | | Maximum bucket name length | 63 characters | | Maximum object name length | 1024 characters | | Maximum `/` separated object name segment length | 255 characters | ## Object conflicts [Section titled “Object conflicts”](#object-conflicts) Objects must have names that are unique and do not conflict with their parent objects. For example, the second request in this sequence will fail because it conflicts with the first object: ```txt PUT /xxx/yyy/textfile.txt PUT /xxx/yyy ``` The same conflict can happen in the opposite order: ```txt PUT /xxx/yyy PUT /xxx/yyy/textfile.txt ``` To avoid this, make sure object names are unique and do not conflict with parent object names. # Object Storage Pricing > Understand how Object Storage billing works in Sliplane. Sliplane Object Storage is billed by total stored data across all buckets in your team. Note All prices are listed excluding VAT. VAT might be added depending on the billing address you provide during checkout. ## Price [Section titled “Price”](#price) Object Storage costs **€5 per month for each 250 GB block**. Storage is counted across all buckets in the team, not per bucket. | Average stored data | Monthly cost | | ------------------- | ------------ | | 1 GB | €5 | | 10 GB | €5 | | 250 GB | €5 | | 251 GB | €10 | | 500 GB | €10 | | 501 GB | €15 | ## Billing examples [Section titled “Billing examples”](#billing-examples) These all cost €5 per month: * 10 buckets with 1 GB each * 5 buckets with 50 GB each * 1 bucket with 250 GB If your team stores 251 GB total across all buckets, the cost is €10 per month. ## Average storage usage [Section titled “Average storage usage”](#average-storage-usage) Object Storage is billed based on average stored data over the billing period. For example, if you upload 1 TB, keep it for 15 days, and then delete it, you effectively used about 500 GB for the month. That would be billed as two 250 GB blocks. ## No bandwidth or request fees [Section titled “No bandwidth or request fees”](#no-bandwidth-or-request-fees) Sliplane does not charge for Object Storage ingress, egress, or API requests. Your Object Storage bill is based only on stored data. # Cloudflared > Set up Cloudflare Tunnel with cloudflared to expose private Sliplane services without opening inbound ports. [Cloudflared](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) is the client for Cloudflare Tunnel. It runs next to your private services, creates an outbound tunnel to Cloudflare, and lets Cloudflare route traffic to your services without exposing public ports on Sliplane. This guide will give an example of how to set up Cloudflared on Sliplane and add a published application. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * A [Cloudflare account](https://dash.cloudflare.com/) * A domain added to Cloudflare * A Sliplane server with private services you want to expose ## Step 1: Get Your Cloudflare Tunnel Token [Section titled “Step 1: Get Your Cloudflare Tunnel Token”](#step-1-get-your-cloudflare-tunnel-token) 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) 2. Go to **Networking** > **Tunnels** 3. Click **Create Tunnel** 4. Give your tunnel a name and click **Create Tunnel** 5. Select **Docker** 6. Copy the token from the install command The token is the long string after `--token` in the Docker command. ## Step 2: Deploy Cloudflared on Sliplane [Section titled “Step 2: Deploy Cloudflared on Sliplane”](#step-2-deploy-cloudflared-on-sliplane) Use the Cloudflared preset to create the service: [Deploy Cloudflared](https://sliplane.io/app/deploy?presetId=cloudflared) Before deploying, replace the placeholder for environment variable `TUNNEL_TOKEN` with the token from Step 1. After deployment, go back to the Cloudflare dashboard. The tunnel should show as **Healthy** within a few seconds. ## Step 3: Add a Published Application [Section titled “Step 3: Add a Published Application”](#step-3-add-a-published-application) In the Cloudflare dashboard: 1. Go to **Networking** > **Tunnels** 2. Click your tunnel 3. Open the **Routes** tab 4. Click **Add route** > **Published application** 5. Set the **Subdomain** and **Domain** you want to use 6. Set the **Service URL** to your Sliplane service’s internal hostname and port For example, if your private service is called `my-service` and listens on port `3000`, use: ```text http://my-service.internal:3000 ``` Cloudflared can reach private Sliplane services on the same server through their `.internal` hostnames. Public traffic goes to Cloudflare first, then through the outbound tunnel to your private service. ## Step 4: Access Your Service [Section titled “Step 4: Access Your Service”](#step-4-access-your-service) Once the route is saved, open the domain you configured in Cloudflare: ```text https://app.example.com ``` The service remains private on Sliplane. Only Cloudflared connects to it internally. ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) **Tunnel disconnected:** * Make sure the status of the tunnel is `Healthy` in the Cloudflare dashboard * Verify that `TUNNEL_TOKEN` is set correctly * Check the service logs in Sliplane **Requests are not reaching your service:** * Verify the internal hostname and port in the Cloudflare route * Make sure the target service is running on the **same** Sliplane server * Confirm that the target service is listening on the port you configured **Route works locally but not through Cloudflare:** * Check that your domain is active in Cloudflare * Verify that the published application uses the right hostname * Review Cloudflare Access rules if you enabled access policies See [Cloudflare Tunnel Troubleshooting](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/) for more resources that help you resolve issues with Cloudflare Tunnel connectivity and configuration. # NetBird > Set up NetBird to access your private Sliplane services through a secure mesh VPN. [NetBird](https://netbird.io/) is an open-source peer-to-peer mesh VPN. Once configured, you can access your private Sliplane services using their internal hostnames from any device connected to your NetBird network. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * A [NetBird account](https://app.netbird.io/) * A Sliplane server with services you want to make private ## Step 1: Get Your NetBird Setup Key [Section titled “Step 1: Get Your NetBird Setup Key”](#step-1-get-your-netbird-setup-key) 1. Log in to [NetBird](https://app.netbird.io/) 2. Go to **Setup Keys** in the left menu 3. Create a new setup key or copy an existing one ## Step 2: Deploy NetBird on Sliplane [Section titled “Step 2: Deploy NetBird on Sliplane”](#step-2-deploy-netbird-on-sliplane) Create a new service with the following configuration: | Setting | Value | | ----------- | ------------------------------------ | | **Image** | `docker.io/netbirdio/netbird:latest` | | **Network** | Private (no public access) | Add these environment variables: | Variable | Value | Description | | ---------------------- | -------------------------- | ------------------------------------------- | | `NB_SETUP_KEY` | Your setup key from Step 1 | Used for automatic registration | | `NB_HOSTNAME` | `routing-peer` | The internal name for this peer | | `NB_USE_NETSTACK_MODE` | `true` | **Required** - Enables userspace networking | Caution The `NB_USE_NETSTACK_MODE=true` variable is required for NetBird to work properly in a container environment. ## Step 3: Configure Network Resources [Section titled “Step 3: Configure Network Resources”](#step-3-configure-network-resources) 1. Go to [app.netbird.io/networks](https://app.netbird.io/networks) 2. Select your network 3. Click **Add Resource** 4. Set the address to `*.internal` This allows NetBird to route traffic to all your private Sliplane services. Note You may also need to add this resource to your **Access Policies** to allow traffic from your devices. ## Step 4: Connect Your Local Device [Section titled “Step 4: Connect Your Local Device”](#step-4-connect-your-local-device) 1. Install the [NetBird client](https://netbird.io/docs/how-to/installation) on your local machine 2. Log in to your NetBird account 3. Your device will automatically connect to the mesh network ## Step 5: Access Your Private Services [Section titled “Step 5: Access Your Private Services”](#step-5-access-your-private-services) Once connected, you can access any private service using its internal hostname: ```bash ping my-service.internal curl http://my-database.internal:5432 ``` The traffic goes through the encrypted NetBird tunnel, and your services remain inaccessible from the public internet.  *** ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) **Service not reachable:** * Ensure the NetBird service is running on Sliplane * Check that your local device is connected to NetBird * Verify the `*.internal` resource is configured in NetBird **NetBird container not starting:** * Make sure `NB_USE_NETSTACK_MODE` is set to `true` * Verify your setup key is valid and not expired # Private Networking Overview > Make your Sliplane services private and accessible through VPN or tunnel solutions. By default, Sliplane services can be made public (accessible via the internet) or private (only accessible by other services on the same server). With private networking or tunnel solutions, you can: * Keep your services private on Sliplane * Access them securely through an encrypted connection * Connect services across different servers or networks ## How It Works [Section titled “How It Works”](#how-it-works) 1. Deploy a VPN or tunnel client as a private service on Sliplane 2. Configure it to connect to your private network or tunnel provider 3. Add your private services as network resources 4. Connect from your local devices or route traffic through the provider 5. Access services via their internal hostnames (e.g., `my-service.internal`) ## Private Networking Options [Section titled “Private Networking Options”](#private-networking-options) There are several private networking and tunnel solutions you can use with Sliplane: | Solution | Description | | ---------------------------------------------- | --------------------------------------------------------------- | | [NetBird](/private-networking/netbird) | German, Open-source, peer-to-peer mesh VPN | | Tailscale | Zero-config VPN built on WireGuard | | [Twingate](/private-networking/twingate) | Zero-trust network access | | [Cloudflared](/private-networking/cloudflared) | Cloudflare Tunnel client for routing traffic through Cloudflare | ## Benefits [Section titled “Benefits”](#benefits) * **Security**: Services do not need a public Sliplane endpoint * **Simplicity**: No firewall rules or port forwarding needed * **Flexibility**: Access from anywhere through your chosen network or tunnel provider * **Cost-effective**: No need for additional load balancers or proxies # Twingate > Set up Twingate to access your private Sliplane services through a zero-trust network. [Twingate](https://www.twingate.com/) is a zero-trust network access solution. Once configured, you can access your private Sliplane services using their internal hostnames from any device connected to your Twingate network. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) * A [Twingate account](https://www.twingate.com/) * A Sliplane server with private services you want to access ## Step 1: Add a Resource [Section titled “Step 1: Add a Resource”](#step-1-add-a-resource) 1. Log in to your Twingate admin console 2. Add a new **Resource** 3. Set the address to `*.internal` This allows Twingate to route traffic to all your private Sliplane services. ## Step 2: Deploy the Connector on Sliplane [Section titled “Step 2: Deploy the Connector on Sliplane”](#step-2-deploy-the-connector-on-sliplane) 1. In the Twingate dashboard, go to **Deploy another Connector** 2. Select **Docker** 3. Keep the default settings 4. Copy the generated Docker command You’ll get a command like this: ```bash docker run -d --sysctl net.ipv4.ping_group_range="0 2147483647" \ --env TWINGATE_NETWORK="your-network" \ --env TWINGATE_ACCESS_TOKEN="..." \ --env TWINGATE_REFRESH_TOKEN="..." \ --env TWINGATE_LABEL_HOSTNAME="hostname" \ --env TWINGATE_LABEL_DEPLOYED_BY="docker" \ --name "twingate-connector" \ --restart=unless-stopped \ --pull=always \ twingate/connector:1 ``` In Sliplane, you can paste this command directly when creating a new service — Sliplane will parse it and configure the service automatically. | Setting | Value | | ----------- | -------------------------- | | **Image** | `twingate/connector:1` | | **Network** | Private (no public access) |   ## Step 3: Connect Your Local Device [Section titled “Step 3: Connect Your Local Device”](#step-3-connect-your-local-device) 1. Install the [Twingate client](https://www.twingate.com/download) on your local machine 2. Log in to your Twingate network ## Step 4: Access Your Private Services [Section titled “Step 4: Access Your Private Services”](#step-4-access-your-private-services) Once connected, you can access any private service using its internal hostname: ```bash curl http://my-service.internal ``` The traffic goes through the encrypted Twingate tunnel, and your services remain inaccessible from the public internet. *** ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) **Service not reachable:** * Ensure the Twingate connector is running on Sliplane * Check that your local device is connected to Twingate * Verify the `*.internal` resource is configured in Twingate **Connector not connecting:** * Verify your access and refresh tokens are correct * Check the service logs in Sliplane # Getting Started with Projects > Learn how to get started with Sliplane projects. A project in Sliplane is a collection of services. This is purely an organizational layer and you can decide how to group your services. For example your frontend, backend and background workers could be organized together in a project. Each project has a human-readable name. *** ## Creating a Project [Section titled “Creating a Project”](#creating-a-project) To create a new project, navigate to the [projects dashboard](https://sliplane.io/app) by clicking on “Projects” in the left sidebar or the Sliplane icon on top in the navbar. Now click on “Create Project” and enter any name that helps you to identify your project. You are now ready to add services to your project. If you have any questions or need assistance in setting up your projects, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=Creating%20Projects). We’re always here to help! ## Updating a Project [Section titled “Updating a Project”](#updating-a-project) To update any of your projects, click on the three dot menu icon on the top right of the project card. You can change the project name in the settings tab or delete the project in the ***Unsafe Territory*** tab. ## Deleting a Project [Section titled “Deleting a Project”](#deleting-a-project) You can delete an existing project from the project settings, that you can access by clicking on the three dots on the top right of each project card. Caution Deleting projects will delete all services inside the project. Servers will stay running. # Create a Server > Learn how to get started with Sliplane servers. Before you can deploy a service with Sliplane, you need to create a server first. Servers are running your services and they are able to host multiple services on them. Servers are assigned to your currently active team and get billed on the payment method associated with that team. To get started, head over to the [servers overview](https://sliplane.io/app/servers) and click ***Create Server*** on the top right of the page. You can get here by clicking on ***Servers*** in the left sidebar. ## Location [Section titled “Location”](#location) When creating a server, you can choose from five different locations: * 🇩🇪 Germany * 🇫🇮 Finland * 🇺🇸 US-East * 🇺🇸 US-West * 🇸🇬 Singapore ## Server Types [Section titled “Server Types”](#server-types) Servers differ depending on their CPU, memory and disk size. Choosing the right server heavily depends on your use case. However, most small applications out there, that do not carry out very resource intensive tasks, will go a long way with the instances that Sliplane provides. In general we recommend just starting with the smallest instance and having an eye on CPU, disk and memory usage. Sliplane makes it very easy to scale these servers later on and move services across servers as you need to. You can view all instances that are available on the [pricing section of our homepage](https://sliplane.io/#pricing). ## Additional Info [Section titled “Additional Info”](#additional-info) As an additional info, you can choose a name for your server, so that you can easily identify it later on. ## Startup Time [Section titled “Startup Time”](#startup-time) If you first create a new server, it will usually take less than 5 seconds until you can start deploying services. ## Cost and Free Trial [Section titled “Cost and Free Trial”](#cost-and-free-trial) You will be charged for servers that you create based on the number of minutes that the servers have been running until they are deleted, but you can create a ***demo server*** for free to try out our service, even if there is no payment method in your account. Demo servers are limited in resources and can only be created twice. Caution If you do not have a payment method attached to your team, these **demo servers will be deleted 48 hours after creation** and all data on them will be lost. Demo servers are not a long-term free tier. After adding a payment method, demo servers will be converted to paid servers and will not be deleted. If you are ready and want your data to persist, please add a payment method to your team, which will convert the demo server to a paid server. You can find out how in the [Billing](/teams/billing) section. # Deleting a Server > Learn how you can delete servers from Sliplane. Deleting a server is very straigtforward. From the [servers overview](https://sliplane.io/app/servers) select the server, that you want to delete. Select the ***Unsafe Territory*** tab and then click on the ***Delete Server*** button in order to delete your server. Deleting a server will delete all services and volumes that are mounted on it, so always double check and be careful if there are multiple services and volumes on it. # Metrics > Learn how to monitor your server. Server metrics allow you to easily figure out when it’s time to scale. They can also be used, to identify issues with your code or bundle sizes, debug outages or detect memory leaks. You can find server metrics by clicking on the server that you want to inspect and select the ***Metrics*** tab. ## Core Metrics [Section titled “Core Metrics”](#core-metrics) At this point we provide three core metrics: * CPU usage * Memory usage * Disk usage ### CPU Usage [Section titled “CPU Usage”](#cpu-usage) CPU usage tells you, how hard your server is working. You will see it going up, if your services do some heavy computations or the traffic on your website increases. If the CPU utilization reaches 100%, your server won’t be able to process any more requests, leading to infinite loading times on the client site and potentially breaking stuff. So always keep a close eye on the graph and if necessary scale your system before that happens. ### Memory Usage [Section titled “Memory Usage”](#memory-usage) Each time your service executes a task it loads data into system memory in order to quickly work with it. The more data your applications process the more memory they require. Same as with CPU, this capacity is limited so when you reach 100% stuff might break. ### Disk Usage [Section titled “Disk Usage”](#disk-usage) The disk metric shows how much space is left on your server. Each image, container and the data that they store eat up disk space. If the space is full, deploys will stop working and your apps won’t be able to save any more data. ## Per Service Metrics [Section titled “Per Service Metrics”](#per-service-metrics) By default, the metrics graphs show you the total system usage. You can also break down resource utilization of each service individually, by selecting the service that you want to inspect, from the filter view next to the metrics graphs. Keep in mind, that the sum from all services does not add up to the total system usage, since total system usage also includes other processes that are running on the server, like the web server, the Docker daemon and other OS packages. ## Timeframe [Section titled “Timeframe”](#timeframe) You can choose between five different timeframes, allowing you to inspect metrics of the last * 10 Minutes, * 1 Hour, * 12 Hours, * 24 Hours, * 3 Days. # Reboot a Server > Learn how to reboot Sliplane servers. On the [servers overview page](https://sliplane.io/app/servers) click on the three dot menu on the server card that you want to reboot. Click on the ***Reboot*** option in the menu and confirm the reboot dialog. Note Rebooting a server will lead to downtime of all services that are running on that server. The reboot will take a few minutes at worse, depending on the server type. Note Rebooting will perform a hard shutdown of the server that may result in data loss! Only use this option as a last resort if you really need to. # Scaling a Server > Learn how to scale Sliplane servers. On the [servers overview page](https://sliplane.io/app/servers) click on the server that you want to scale and navigate to the ***Upgrade*** tab. Here you can see an overview over every instance type that is available in the servers location. Select the instance that you want to scale to and click on ***Upgrade*** to start the scaling process. Note Servers can only be scaled up. You are not able to downgrade to a server with less memory. You can view all instances in every location on the [pricing section of our homepage](https://sliplane.io/#pricing). # Server Settings > Learn how to configure Sliplane servers. From the [servers overview page](https://sliplane.io/app/servers) click on the server that you want to configure and you will land on to the server settings page. From here you can see an overview over your machine and you are able to update some of the settings that are explained in more detail in chapter [Create a server](/servers/create-a-server): * Change your servers name # Services > Learn how to manage services on your servers. The server services page will show you an overview over all of the services that are running on your server. You can click on any of the services and be redirected to the project that the service lives in. To get to the services overview, click on [Servers](https://sliplane.io) in the left sidebar of the app, select the server of choice and click on ***Services*** tab. # Volumes > Learn how to manage volumes on your servers. Volumes are a way to persist data from your services. Simply speaking, volumes are folders that get mirrored from inside your container, to a folder on the host server. If you are not familiar with the concept, please check out the official [Docker docs on volumes](https://docs.docker.com/storage/volumes/) first. Go to the [server overview page](https://sliplane.io/app/servers) and select a server to get to the ***Server Settings*** page. From there, select the ***Volumes*** tab. ## Adding Volumes [Section titled “Adding Volumes”](#adding-volumes) Adding a Volume is as simple as clicking on the ***Add Volumes*** button, and specifying a name for it. The volume will then show up in the volumes list on the page. You can later attach this volume to any of your existing services on this server or reference it when deploying a new service. Multiple services can share the same volume. ## Editing Volumes [Section titled “Editing Volumes”](#editing-volumes) Click on the volume that you want to edit. Next click on the three dot menu on the top right of the volume details card next to the volume name and select ***Edit***. You can then modify the volumes name. ## Deleting Volumes [Section titled “Deleting Volumes”](#deleting-volumes) Same procedure as editing, select the volume first, then select ***Delete*** from the three dot menu on top right of the volume details card. Note In order to delete a volume, you need to detach all services, that are linked to it first. Take note, that all data inside the volume will be lost forever if you choose to delete a volume, so be careful not to accidentally delete any data, that you might need later on. ## Volume Backups [Section titled “Volume Backups”](#volume-backups) Volume backups are enabled by default for every volume on the server and will be carried out on a daily schedule. We store backups for 7 days. Caution Depending on your specific use case, volume backups may not fully guarantee data integrity. For instance, in large-scale or high-traffic databases, it is often necessary to implement a customized backup procedure tailored to the system’s demands. We strongly recommend regularly verifying that backups can be successfully restored to ensure reliability and data protection. ### Restoring a Backup [Section titled “Restoring a Backup”](#restoring-a-backup) To restore a volume backup click on the ***restore*** button next to the backup name. Depending on your backup size, this process might take a while. You can come back anytime to check the restore status. When the restore is done, a new volume will be created with the contents of the backup. To finish the process, you need to manually detach your old volume from your service and attach the new one. ### Creating a Backup manually [Section titled “Creating a Backup manually”](#creating-a-backup-manually) You can create a backup manually by clicking on the three-dot-menu on the top right of the volume details card and selecting ***Create Backup***. This will start a backup of the current state of the volume. Manual Backups are limited to one backup per volume every 30 minutes. # Access Control > Learn how to limit access to your services Access to services that use the TCP or UDP protocol can be restricted using allowlist rules. Only IP addresses or subnets that match a rule will be able to reach your service. ## How It Works [Section titled “How It Works”](#how-it-works) When you add one or more allowlist rules to a service, only traffic from the specified IP addresses or subnets is allowed. All other traffic is blocked. If no rules are configured, the service is open to all traffic (default behavior). ## Adding a Rule [Section titled “Adding a Rule”](#adding-a-rule) 1. Navigate to your service settings 2. Find the **Access Control** section 3. Click **Add Rule** 4. Enter an IP address or CIDR range 5. Optionally add a comment to describe the rule (e.g. “Office VPN” or “CI server”) ## CIDR Notation [Section titled “CIDR Notation”](#cidr-notation) Rules use [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) to specify IP ranges, for both IPv4 and IPv6: | Rule | What it matches | | ---------------- | --------------------------------------------------------- | | `203.0.113.10` | A single IPv4 address | | `203.0.113.0/24` | All IPs from 203.0.113.0 to 203.0.113.255 (256 addresses) | | `0.0.0.0/0` | All IPv4 addresses | | `2001:db8::1` | A single IPv6 address | | `2001:db8::/48` | An IPv6 range | | `::/0` | All IPv6 addresses | Common IPv4 subnet sizes: * `/32` - single IP (same as specifying the IP without a prefix) * `/24` - 256 addresses (e.g. `192.168.1.0/24`) * `/16` - 65,536 addresses (e.g. `172.16.0.0/16`) ## Managing Rules [Section titled “Managing Rules”](#managing-rules) You can update or delete existing rules at any time. Changes take effect shortly after saving. Each rule can have an optional comment to help you remember what the rule is for, which is especially useful when managing multiple rules. Note Access control rules are only available for TCP and UDP services. HTTP services can use other methods like [Basic Auth](/guides/basic-auth) or private networking with [NetBird](/private-networking/netbird) or [Twingate](/private-networking/twingate) to restrict access. # Custom domains > Learn how to connect a custom domain to your service By default, your services are assigned a free subdomain on sliplane.app. On top, you can easily connect a custom domain to your service with just a few clicks. Plus, when you add a custom domain, SSL/HTTPS is automatically set up for your http services. *** ## Connecting a custom domain [Section titled “Connecting a custom domain”](#connecting-a-custom-domain) Before connecting your custom domain, please ensure that your service has been created and deployed successfully, and that it can be reached on the sliplane.app subdomain. Once you’re ready, make sure you have access to the DNS settings of your domain. If you’re not sure where to find this option, check your domain registrar’s control panel. To connect your custom domain, navigate to your service in the Sliplane dashboard and go to the Settings tab. You will find a section called “Domain”. Click on the “Connect Domain” button, which is only available if your service is healthy. Then, a popup will appear, prompting you to enter your entire domain, such as [www.example.com](http://www.example.com), or example.com. After entering your domain, click on “Connect”. You will then see information on how to update your DNS settings. You have three options to choose from, but you only need to pick **one**. You can set up a CNAME record, an ANAME or ALIAS record, or A and AAAA records. If you’re not sure which option to choose, we recommend using the CNAME record. However, all options will have the same end result. ### CNAME records [Section titled “CNAME records”](#cname-records) CNAME records map one domain name to another. If your custom domain is [www.example.com](http://www.example.com), add “www” as the host value and your xyz.sliplane.app subdomain as the value. If you want to use the root domain (example.com), add ”@” (or whatever your registrar is expecting for as a root value) as the host value and your xyz.sliplane.app subdomain as the value. Note Not all DNS providers support CNAME records for the root domain (example.com). If you’re not sure, you can try adding a CNAME record for the root domain. If it doesn’t work, you can always remove it and try one of the other options. ### ANAME/ALIAS records [Section titled “ANAME/ALIAS records”](#anamealias-records) ANAME or ALIAS records are similar to CNAME records, but they can be usually used for the root domain (*example.com*) if CNAME root records are not allowed by your registrar. If your DNS provider supports ANAME or ALIAS records, you can add your **xyz.sliplane.app.** subdomain as the value for your own domain *example.com* or *sub.example.com*. ### A and AAAA records [Section titled “A and AAAA records”](#a-and-aaaa-records) A and AAAA records are the most basic DNS records. They map a domain name to an IP address. If you choose this option, you will need to add two records. One for the IPv4 address and one for the IPv6 address. You can find the IP addresses in the popup after clicking on “Connect Domain”. Create an A record with the host value (your subdomain or ”@” if your domain is example.com and not sub.example.com) and the IPv4 address as the value. Then create an AAAA record with the same host value as before and the IPv6 address as the value. *** ## Wildcard domains [Section titled “Wildcard domains”](#wildcard-domains) We also support wildcard domains (e.g. `*.example.com`). Wildcard domains are free of charge and after the initial setup fully automated. To set up a wildcard domain, [contact us](mailto:support@sliplane.io?subject=Wildcard%20Domain) with your domain and use case, and we’ll get it configured for you. *** If you have any questions or need assistance in setting up your custom domain, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=Custom%20Domain). We’re always here to help! # Deploying a Service > Learn how to create a new service in Sliplane A service in Sliplane is your application running on a server, along with its configuration. A service might be a website, a backend API, a recurring job, a database or anything else you want to run on your server. Under the hood every service runs in a container, but you don’t need to know anything about Docker to deploy one. You can deploy straight from a GitHub repository — with or without a Dockerfile — or pull a prebuilt image from a registry. To create a new service, select a project first and then click ***Deploy Service*** at the top right corner of the page. ## Project [Section titled “Project”](#project) The project is usually preselected for your. If not, you can select a project in the first step of the deploy process or change the preselected project here. ## Deploy to Server [Section titled “Deploy to Server”](#deploy-to-server) After choosing a project, you need to select a server, where the service should be deployed to. If you have not done so already, [create a server](/servers/create-a-server) first, where you can deploy your service to. Each server can host multiple services, you get charged per server and you can deploy as many services as the server can handle. ## Services [Section titled “Services”](#services) In the last step, you need to add configuration for your services, that you want to deploy. You can deploy multiple services in one go, by clicking the ***Add service*** button on screen. ### Deploy source [Section titled “Deploy source”](#deploy-source) You can either deploy from a GitHub repository or deploy from a registry. * **From GitHub** — deploy your own code. A Dockerfile is optional: if your repo contains one we use it, and if it doesn’t, Sliplane detects your application’s stack and builds it for you with [Railpack](https://railpack.com/), so no Docker knowledge is required. * **From a registry** — pull a prebuilt image from any OCI-compatible container registry. Additionally we provide the option to deploy some pre configured public images from Docker Hub. These include PostgreSQL, MongoDB, MySQL, MariaDB and more. Under the hood, it’s the same thing like deploying a public image from Docker Hub, but we already prefill all the necessary configuration to get the image up and running with just a single click. Tip For object storage, see [Object Storage](/object-storage/getting-started). ### Deploy from GitHub [Section titled “Deploy from GitHub”](#deploy-from-github) You can deploy services by selecting a repository from GitHub. A Dockerfile is optional — if your repository contains one, Sliplane will use it. If it doesn’t, Sliplane will automatically detect your application’s stack and build it for you using [Railpack](https://railpack.com/). Note Docker compose files do not work yet. For now, you’d have to spin up each service individually or use our built in Docker compose parser to extract service configuration from a docker-compose.yml file. Sliplane will do the following: 1. Pull the latest state of your codebase 2. Build a Docker image from your repository — using your Dockerfile if one is present, or by auto-detecting your application’s stack and building it for you with [Railpack](https://railpack.com/) 3. Start a container from the image and if specified, expose your service 4. Validate that the container is running 5. Redirect traffic to the new container Note Please make sure that you have the necessary permissions to deploy the repository you selected. You need to be an admin of the repository and have write access at least. You can find more details in the [GitHub integration documentation](/more/github/). To get started, select ***GitHub*** as a deploy source in the deploy form. This setting is usually preselected by default. #### Select a Repository [Section titled “Select a Repository”](#select-a-repository) Next, choose the repository from the dropdown menu, that you want to deploy. Take note that you have to allow Sliplane to access the repository in your GitHub account first. In the “Select a Repository” dropdown, click “Configure Repository Access”. This will redirect you to your GitHub Account, where you can manage Sliplanes access to your repositories. You can read more about what Sliplane is doing in the [GitHub](/more/github) chapter. Note It might take a minute after you saved your settings in GitHub, until the repository will show up in Sliplane. Hit the “Refresh List” button at the end of the dropdown, to check if the repository became available. #### Select a Deploy Branch [Section titled “Select a Deploy Branch”](#select-a-deploy-branch) Select the branch of your repository that should be deployed. By default new commits on this branch will be deployed automatically. After your first deploy, this setting can be changed in your services settings by disabling the “Automatically deploy new commits” toggle. #### Dockerfile Path [Section titled “Dockerfile Path”](#dockerfile-path) The Dockerfile path specifies the path to a Dockerfile inside your repository, that should be used to build your Docker image. Sliplane will try to find a Dockerfile in your repository and prefill this setting for you. If you renamed your Dockerfile or you are using a monorepo with multiple Dockerfiles, this initial guess might be wrong and you’ll have to update the setting here. Make sure to always end the path with the filename e.g. `/app/Dockerfile` If no Dockerfile is found in your repository, Sliplane will automatically detect your application’s stack and build it for you using [Railpack](https://railpack.com/) — leave this field empty in that case. #### Docker context [Section titled “Docker context”](#docker-context) This option defines a directory of your repository that serves as the root for all commands in your Dockerfile. The default `/` points to your repository root. Say your Dockerfile contains a `COPY . .` instruction. This command will copy everything from the root directory of your repo to your image. But what if your repository contains multiple folders, with multiple Dockerfiles in it and each Dockerfile should only copy the contents of its parent folder? In that case you would specify the Docker context to point to the folder containing the Dockerfile. A `COPY . .` instruction will then only copy the contents of that folder. ### Deploy from a Registry [Section titled “Deploy from a Registry”](#deploy-from-a-registry) You can also deploy container images from any OCI-compatible container registry. Sliplane will do the following: 1. Pull your image from the registry 2. Start a container from the image with the config you provide through Sliplane 3. Validate that the container is running 4. Redirect traffic to the new container In the deploy form, select “Registry” as a deploy source up top. #### Image URL [Section titled “Image URL”](#image-url) The URL pointing to the image in your registry. Make sure to stick to the following format: On Docker Hub : `docker.io/namespace/image-name:tag` On GitHub Container registry: `ghcr.io/namespace/image-name:tag` Examples: `docker.io/grafana/grafana:9.5.20` `docker.io/library/postgres:16.2` `ghcr.io/sliplane/file-upload:latest` Make sure to enter the URL without the networking protocol (no http or https). If the namespace for an official public image on Docker Hub is not explicitly specified, it becomes “library”. Alternatively you can search for a public image on Docker Hub. Type the name of your image inside the “Image URL” text input. Make sure to type the image name exactly as it is, or otherwise it might not be found. Select the version of your image by choosing a search result from the list. Note The “Latest” tag setting is not recommended in a production setting. A redeploy will always download the newest version of this image which can lead to unintended upgrades of new code that has not yet been tested agains other parts of your application. So in production applications better choose an explicit tag. ### Credentials [Section titled “Credentials”](#credentials) If your image is private you can access it by providing an authorized credential or in other words your username and password or access token. In Sliplane, your credentials are stored on team level, meaning everyone in the team can use them. Choose a credential from the dropdown or add a new one if you need to. You can read more about registry credentials in the [teams section](/teams/registry-credentials). Note When using the GitHub (GHCR) credential type, only “classic” GitHub personal access tokens starting with `ghp_...` are supported. Alternatively, you can use the “Generic” credential type which works with any token format and any container registry. ### Expose Service [Section titled “Expose Service”](#expose-service) If your service should be reachable over the internet, activate this toggle. This applies to websites for example or public APIs. Sliplane currently supports only one public port per service. It will try to detect the port automatically, but in some cases a service might expose multiple ports. You can then specify the port manually by adding a `PORT` environment variable e.g `PORT=3000`. In case your service does not need to be accessible from the outside world, you can turn of that switch for an additional layer of security. In that case, only services that are running on the same server can communicate with your service. This setting can be useful for an internal API or a private database, that should only be accessible from your backend on the same machine. You can reach private services on the same server through the internal host domain that you can find in the service settings. Note This setting can not be changed later on! If you want to change it, you need to redeploy the service. You can make use of the “Deploy Copy” feature. #### Networking protocol [Section titled “Networking protocol”](#networking-protocol) Select the networking protocol for your service. Most of the services, that get deployed via Sliplane, are communicating via “TCP/HTTP”. This is the default setting. However, some applications use more low level protocols to communicate like “TCP” or “UDP”. Databases for example are usually not accessible via HTTP, so you need to change the protocol there. #### Health check route [Section titled “Health check route”](#health-check-route) For HTTP services, you can specify a health check route. This route will be used to validate, that deploys have been successfull and to regularly check, if your service is still running. Sliplane will perform these health checks against the exposed port that is automatically detected. In case your service listens on multiple ports, you can specify the port manually via the `PORT` environment variable. For example, if you add **/**, we will check at ****. If you add **/health**, we will check at ****. If you don’t add a health check, we will use **/** as default. It’s important that a GET request on the health check route of your app returns a 2XX status code and no authentication is required, otherwise deploys will fail. Sliplane will hit this route after each deploy and only redirect traffic to the new version of your service, once health checks are green. Healtch checks are also performed in 1 minute intervals to check whether your app is still running. If they fail 3x in a row, you will get notified via email. ### Environment Variables [Section titled “Environment Variables”](#environment-variables) Environment variables are a great way to configure your service and keep secrets out of your code. For example, you might want to add a **DATABASE\_URL** environment variable that contains the connection string to your database or a **BASE\_URL** that specifies the domain your service is currently running on. Sliplane supports environment variables out of the box. These environment variables are available to your service as process environment variables (during build and runtime!) and if no **.env** file exists in the root of the project (it shouldn’t!), Sliplane will create one for you with the environment variables you have configured. The **.env** has the following format: ```text KEY1=VALUE1 KEY2=VALUE2 ... ``` You can either set environment variables as key-value pairs, or paste the content of your **.env** file. After creating an environment variable, you can toggle it to be a secret. Once the secret toggle is enabled, the value can no longer be viewed again. Note Do not use ***localhost*** in your environment variables, since this won’t work with Docker. Instead, use ***0.0.0.0***. Note All environment variables will be stored encrypted #### Reserved keys [Section titled “Reserved keys”](#reserved-keys) Certain keys are used internally by the Sliplane client and can not be overwritten by you. The keys and explanation can be found in the following list: **PORT**: The PORT variable is used by the Sliplane to tell your service on which port to listen. It should be in the range of 8080 to 65535. If your service is exposed to the internet via HTTP and fails to listen to the specified port the deployment and healthchecks will fail. **SLIPLANE\_COMMIT\_HASH**: The git commit hash of the current deploy. **SLIPLANE\_DOMAIN**: The managed domain (e.g. **your-service-name.sliplane.app**) of the service. **SLIPLANE\_SKIP\_CACHE**: If set to **true**, the Docker build cache will be skipped. **SLIPLANE\_GRACE\_PERIOD**: Time in seconds that Sliplane will wait for your container to start, before cancelling the deploy. **SLIPLANE\_USER\_ID**: Specify the user id that owns volumes, that are attached, e.g. 1000 **SLIPLANE\_GROUP\_ID**: Specify the group id that owns the volumes, that are attached e.g. 1000 #### Variables in environment variables [Section titled “Variables in environment variables”](#variables-in-environment-variables) You can reference other environment variables within your environment variable values. For example, you might use the **SLIPLANE\_DOMAIN** variable or any other variable you’ve defined. Use the syntax `${VARIABLE_NAME}` or `$VARIABLE_NAME`. For example: ```bash DOMAIN=${SLIPLANE_DOMAIN} DATABASE_URL=postgres://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME} ``` ### Volumes [Section titled “Volumes”](#volumes) Containers are ephemeral. This means, that they get spun up and destroyed quite frequently, and when that happens all data inside is deleted as well. For that reason, it is not recommended to store any data inside a container, that should persist. If your application relies on data that needs to persist between deploys you can attach a volume to your service. Simply speaking, a volume mirrors a folder inside your container and stores it on the host system. That way, when the container is teared down, the folder still persists and you can keep all data inside it. To mount a volume to your service, you need to specify the mount path, pointing to a folder inside your service that should persist. Note The mount path is the absolute path from your container root. If your app inside the container is running in a workdir you also have to include it in your mount path. Note Mounting a volume will disable zero downtime deploys. This is necessary to avoid data corruption. When you deploy a new version of your service, the old container won’t be available for a couple of seconds. ### Service Name [Section titled “Service Name”](#service-name) Enter a name for your service. The default is your repository name. Your subdomain will be **your-service-name.sliplane.app** if available. ### Override CMD [Section titled “Override CMD”](#override-cmd) Overrides the CMD instruction in your Dockerfile. This setting is optional. The CMD instruction sets the command to be executed when running a container from an image. It can be a bash command, for example, if your Docker container is able to execute bash: Example: `echo "Hello World!"` You can find more details in the official Docker documentation: . Note that you need to provide the command as a string, just as you would type it in your terminal, as opposed to using array syntax `["echo", "hello world"]`, which will not work. ### Using the Docker Command Parser [Section titled “Using the Docker Command Parser”](#using-the-docker-command-parser) After clicking “Add service” you can also make use of our Docker Command Parser. This tool can help you to extract configuration from an existing Docker run command or Docker compose file and translate it into the Sliplane service configuration format. To use the parser click on the terminal icon in the top right corner of the “Add service” form. You can then paste your Docker run command or Docker compose file contents into the text area and click “Add service”. The parser will then try to extract services for you. You can also provide environment variables that can be used in the Docker command or compose file using `${VARIABLE_NAME}`. Note The parser only supports a subset of all possible Docker run flags and Docker compose options. It pulls out service definitions, volumes and environment variables and applies some common sense defaults. It is strongly recommended to review the generated configuration before deploying the service. If multiple services are referencing each other through their internal hostnames, the parser will try to replace the hostnames with the internal hostnames that Sliplane generates for each service. These hostnames referenced in the environment variables using `$SERVICE_NAME.INTERNAL_HOST`. ## What happens if a new deploy fails? [Section titled “What happens if a new deploy fails?”](#what-happens-if-a-new-deploy-fails) If you push code and the build or start command fails, we will not redirect the traffic to the new version of your application. Instead, we will keep the previous version of your application online. This way, your users will not experience any downtime. You will also be able to see the logs of the failed deploy in the logs section of your service! *** If you have any questions or need assistance in setting up your service, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=Service). We’re always here to help! # Logging > Learn how logging for your serices works. For every service you create we automatically log the output of your started process. We store logs of the the last 7 days (max. 15000 loglines) which can be seen in your Sliplane service dashboard. As always, be careful not to log any sensitive information. You can filter logs by time, search for specific terms and filter based on the type (runtime and build logs). We are also working on improving the logging experience. If you have any questions, feedback, or want to be the first to try it out, please [contact us](mailto:support@sliplane.io?subject=Sliplane%20Logging). # Pausing Services > Learn how to pause your services You can pause a service on the service settings page or in your project overview (three dots on the right side of the service name). Pausing a service stops the container from running, but it does not delete the service, its data, or its configuration. You also keep the domain. Pausing/Resuming the service usually takes around 10 seconds, accessing the domain of a paused service should result in a timeout eventually. # Service events > Learn about service events. Service events show you a history, of important events. They include: * ***Deploy events***, like successful and failed deploy events along with the error message, why the deploy failed * ***Domain events***, like successfuly connection, removal of domains or failed ones * ***Healthcheck events***, to tell you when your service went down * ***Volume events***, like successfull and failed attachments of volumes # Service Settings > Learn how to configure your services. To get to the service settings, navigate to the project, that contains your service and then click on the service, that you want to configure. ## Settings [Section titled “Settings”](#settings) The service settings show an overview over all of the settings, that you used to deploy your service. If you need a more detailled explanation about these settings, please read chapter [Deploying a Service](/services/deploying-a-service). You can update many, but not all of these settings. Updating any configuration here, will automatically trigger a redeploy of your service. Settings that can’t be changed are: * the deploy source, you can’t switch from GitHub to a registry (or vice versa) * whether the service is exposed publically or it is accessible on your server only * the protocol to communicate with your service (HTTP, TCP, UDP) * the server this service has been deployed to Note If you need to change any of these unchangeable settings or move to a different server, you can easily deploy a copy of your service via the ***Deploy Copy*** feature. The feature can be found in the project page by clicking on the three dot menu on the service that you want to copy. ## Deploy rules [Section titled “Deploy rules”](#deploy-rules) For services deployed from a repository, you can add deploy rules to control when deploys are triggered. This is especially useful for monorepos, where you typically don’t want to build every part of your application on every new commit. * Autodeploy: Toggle this, if you want to deploy new commits automatically. Otherwise, you can use the deploy hook to trigger new deploys. * Include Paths: Only deploy if the commit contains changes in one of the included paths. * Ignore Paths: Skip deploys if the commit only contains changes in on of the ignore paths. You can set both ignore paths and include paths. Ignore and Include paths can either be an exact match of a file `path/to/file` or a [glob pattern](https://en.wikipedia.org/wiki/Glob_\(programming\)) `path/to/*.js`. Not specifying any paths will match all paths. If any changed file matches the include paths (or its empty) while none matches the ignore paths, Sliplane will deploy. #### Glob Patterns [Section titled “Glob Patterns”](#glob-patterns) Glob patterns match filenames using wildcards: `*` matches any sequence of characters (except /), `?` matches any single character, and character classes like `[abc]` match any enclosed character. Common examples: `src/backend/**/*`, `src/frontend/**/*`, `src/**/*`, `package.json`. ## Service Info [Section titled “Service Info”](#service-info) ### Service Status [Section titled “Service Status”](#service-status) The service status shows you instantly, whether you service is running or not. It can either be * Up if everything is fine, * Down if your service has been deployed, but it is currently not running. * Paused if your service is paused. * Pending if your service has not yet been deployed, but the deploy is in progress. ### Deploy Status [Section titled “Deploy Status”](#deploy-status) The deploy status shows * Deploy Live for successful deploys, * Deploy Failed for unsuccessful deploys, * Deploy in Progress for deploys in progress. Apart from the first deploy, the deploy status is independent from your service status. If a deploy fails, it does not bring down your service. Sliplane first spins up a new version of your service and only redirects traffic, if it can verify that the service is running. ### Deploy Hook [Section titled “Deploy Hook”](#deploy-hook) A GET request to this URL will trigger a new deploy of your service. Keep this URL secret, as anyone with it can control deploys of your service. ### Domain / Internal Host [Section titled “Domain / Internal Host”](#domain--internal-host) Public services are hooked up with a …sliplane.app domain in order to access them over the internet. If your service is private, you will see the internal host of your service here that you can use to connect to your service, from other services on the same server. For TCP and UDP services, the domains ends with a port, that is used to find your service on the server. ### Repository [Section titled “Repository”](#repository) If you deployed from GitHub, you can find a link to your GitHub repository here. ### Public Image [Section titled “Public Image”](#public-image) If you deployed from a container registry, you can find a link to the image here. ### Server [Section titled “Server”](#server) This links to the server, where your service was deployed on. # SSH > Learn how to connect to your services via SSH. ## SSH Access Methods in Sliplane [Section titled “SSH Access Methods in Sliplane”](#ssh-access-methods-in-sliplane) Sliplane offers two ways to connect to services via SSH: [Direct SSH to Container ](/services/ssh#direct-ssh-connection)Execute commands directly in your container. Great for debugging and admin tasks. Supports SCP and rsync if installed in the container. [SSH Tunneling ](/guides/ssh)Access private services in the same Docker network. Supports full SSH functionality including SCP, rsync, and port forwarding. ## Direct SSH Connection [Section titled “Direct SSH Connection”](#direct-ssh-connection) This method connects you directly into a specific container’s shell. ### Prerequisite [Section titled “Prerequisite”](#prerequisite) You need to have an SSH key pair set up on your local machine. You can follow [this guide](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) in order to generate an SSH key pair and add it to your SSH agent. ## Attach your SSH key to a service [Section titled “Attach your SSH key to a service”](#attach-your-ssh-key-to-a-service) * Navigate to the service that you want to connect via SSH * Click on the “SSH” tab in the service dashboard * Click on “Attach SSH key” * Select your SSH key from the list or click on “Add new key” if you haven’t added any SSH keys to your account yet Note You can also manage all of your SSH keys in your [account settings](https://sliplane.io/app/account/ssh) in the SSH tab. ## Connect to your service via SSH [Section titled “Connect to your service via SSH”](#connect-to-your-service-via-ssh) After attaching your SSH key to a service, you can see the SSH command that you can use to connect to your service. Example SSH command: ```bash ssh -p 22222 service_12345@server_domain ``` Copy and run the SSH command that is displayed in your terminal in order to connect to your service. # Volumes > Learn how to attach volumes to your service Volumes are a way to persist data from your services. Simply speaking, volumes are folders that get mirrored from inside your container, to a folder on the host server. If you are not familiar with the concept, please check out the official [Docker docs on volumes](https://docs.docker.com/storage/volumes/) first. ## Attach a Volume [Section titled “Attach a Volume”](#attach-a-volume) Click on ***Attach a Volume*** and select a volume from the dropdown list of all volumes on the server. Multiple services can use the same volume to store data. If you select a volume from the list, you will be promted to provide a path to a folder inside your container, that will be mirrored. Note The mount path is relative to the root directory of your container. It might be different than the path inside your app. For example if your Dockerfile contains instructions to create a work directory, it’s important that you include this workdirectory in the path. The path needs to end with the folder name. You can also click on ***Create new Volume*** inside the volumes dropdown menu, in order to create a new volume on the server. In that case, also specify a name for the volume alongside the mount path. ## Detach a Volume [Section titled “Detach a Volume”](#detach-a-volume) To detach a volume, simply select the volume and hit ***Detach*** on the top right next to the volume name. This will disconnect your service from the volume, but the volume and it’s data will remain on the server until you delete it. # API Keys > Learn how to create and manage API keys for the Sliplane API. API keys allow you to programmatically manage your Sliplane resources through the [Sliplane API](https://ctrl.sliplane.io/#description/introduction). ## Creating an API Key [Section titled “Creating an API Key”](#creating-an-api-key) To create an API key, navigate to the [API tab](https://sliplane.io/app/team/api) in your team settings. If your team doesn’t have API access yet, you can request it from there. Once approved, you can create API keys with either read-only or read-write permissions. Caution API keys are shown only once when created. Make sure to copy and store them securely. ## Permissions [Section titled “Permissions”](#permissions) API keys can have one of two permission levels: * **Read-only**: Can view resources but cannot create, update, or delete them * **Read-write**: Full access to manage all resources in the team ## Managing API Keys [Section titled “Managing API Keys”](#managing-api-keys) You can view and delete your existing API keys from the [API tab](https://sliplane.io/app/team/api). If you suspect a key has been compromised, delete it immediately and create a new one. # Billing & Pricing > Understand Sliplane's simple per-server pricing model, per-hour billing, and bandwidth fair use. ## Billing Portal [Section titled “Billing Portal”](#billing-portal) You can manage all billing related issues through the billing portal, like: * adding and updating the payment method for your team * viewing and downloading invoices * updating your billing address To access the billing portal, navigate to the [billing page](https://sliplane.io/app/team/billing) and click on “Manage billing data”. You will be redirected to our payment provider “Stripe” where you can carry out any of the tasks listed above. Note We do not store any payment data ourselves. This is handled by our payments provider Stripe in order to ensure secure handling of your payment data. ## How Billing Works [Section titled “How Billing Works”](#how-billing-works) Sliplane uses a straightforward **pay-per-server** pricing model. Note All prices are listed **excluding VAT**. VAT might be added depending on your billing address that you provide during checkout. ### Per-Team Billing [Section titled “Per-Team Billing”](#per-team-billing) Billing is managed on a per-team basis. Each team has its own separate subscription and billing information. ### Per-Server Pricing [Section titled “Per-Server Pricing”](#per-server-pricing) Unlike many platforms that charge per service, container, or resource, Sliplane charges **per server**. You can deploy as many services on a server as it can handle - your frontend, backend, background workers, and more - all for one fixed price. **Example**: A React frontend, a Node.js API, and a background worker can all run on a single Starter server (€9/month). ### Per-Hour Billing [Section titled “Per-Hour Billing”](#per-hour-billing) Sliplane bills by the hour, not by the month. Here’s what that means: * We calculate the per-hour rate from the monthly price * You’re billed for the exact time your server exists (from creation to deletion) * If you keep a server for only 14 days, you only pay for 14 days #### Billing is Time-Based, Not Usage-Based [Section titled “Billing is Time-Based, Not Usage-Based”](#billing-is-time-based-not-usage-based) Your bill is based on how long your server exists, **not** on how much you use it: * An idle server costs the same as a busy server * Paused or stopped services still incur server costs * The only way to stop charges is to **delete the server** When you see “usage based” in the billing portal, this refers to the hours your server has been running, not CPU or traffic usage. #### Why Monthly Bills Vary Slightly [Section titled “Why Monthly Bills Vary Slightly”](#why-monthly-bills-vary-slightly) Since we bill per hour, and months have different lengths (28-31 days), your monthly total may vary slightly. It averages out to the advertised monthly price over time. **Example calculation for a Starter server (€9/month):** * Average month: 30.42 days * Per-hour rate: €9 ÷ 30.42 ÷ 24 ≈ €0.0123 * 14 days = 14 × 24 hours × €0.0123 ≈ **€4.15** #### Billing Cycle and Billing Threshold [Section titled “Billing Cycle and Billing Threshold”](#billing-cycle-and-billing-threshold) Every customer has a billing threshold, starting at **2€**. The first time your usage exceeds this amount, your payment method will be charged. After that, the threshold increases gradually. We bill monthly at the end of a billing period or if your usage exceeds the billing threshold earlier. The billing threshold can be reset if you change your payment method or if payments fail repeatedly. #### How to Stop Billing [Section titled “How to Stop Billing”](#how-to-stop-billing) If you want to stop billing you have to delete all servers in your team. Note that you might still get a final invoice for unbilled usage up to the point of deletion. ## Server Pricing Tiers [Section titled “Server Pricing Tiers”](#server-pricing-tiers) Servers start at **€9/month + VAT** for the Starter configuration. For the full list of server sizes and configurations, see our [pricing page](https://sliplane.io/#pricing). ## Bandwidth [Section titled “Bandwidth”](#bandwidth) Ingress and egress bandwidth are included with every server at no extra cost under our [Fair Use Policy](https://sliplane.io/fair-use). There are no hard bandwidth caps and we do not throttle your server. If your server stays under **1TB of outbound traffic per month**, you are clearly within fair use. If you expect or are already seeing more than that, please [contact support](mailto:support@sliplane.io) so we can understand your use case. Short bursts are usually not an issue; we look at sustained usage patterns. ## Object Storage Pricing [Section titled “Object Storage Pricing”](#object-storage-pricing) Object Storage is billed separately from servers. It costs **€5 per month for each 250 GB block** of average stored data across all buckets in your team. Prices are listed excluding VAT. Sliplane does not charge for Object Storage ingress, egress, or API requests. For details and examples, see [Object Storage Pricing](/object-storage/pricing). ## Common Scenarios [Section titled “Common Scenarios”](#common-scenarios) Here are some typical use cases and their costs. ### Small Project [Section titled “Small Project”](#small-project) A typical small project with a frontend and backend API: * **Setup**: 1 Starter server (€9/month) * **Services**: React app, Express API * **Monthly cost**: €9 + VAT ### Testing Environment [Section titled “Testing Environment”](#testing-environment) Spin up a server for quick testing: * **Duration**: 3 days * **Server**: Starter (€9/month) * **Cost**: 3 days × 24 hours × (€9 ÷ 30.42 ÷ 24) ≈ **€0.89** ### Multiple Environments [Section titled “Multiple Environments”](#multiple-environments) Running dev, staging, and production: * **Setup**: 3 Starter servers * **Monthly cost**: 3 × €9 = €27 + VAT ## Summary [Section titled “Summary”](#summary) * **Per-server pricing**: Unlimited services per server * **Per-hour billing**: Pay only for the time your server exists * **Free ingress and egress bandwidth**: Included under our fair use policy Questions about billing? [Contact our support team](mailto:support@sliplane.io). # Deleting a Team > Learn how to delete a Sliplane team. To delete your team, navigate to the “[Unsafe territory](https://sliplane.io/app/team/delete)” and click “Delete Team”. Take note that you need to delete all servers in your team first in order to be able to delete it. Your default team can not be deleted. # Getting Started with Teams > Learn how to get started with Sliplane teams. Teams in Sliplane are used to group servers, projects and services. You can create as many teams as you like, and each team has its own subscription and billing. Every user has its own personal team. This team is created automatically when you sign up for Sliplane and can not be deleted unless you close your Sliplane account. *** ## Creating a Team [Section titled “Creating a Team”](#creating-a-team) To create a new team, click on the Team dropdown in the top navigation bar and select “Add Team”. You can then enter a name for your team and click “Create Team”. After creating a team, you will be redirected to the dashboard of the newly created team. If you have any questions or need assistance in setting up your team, please do not hesitate to [contact us](mailto:support@sliplane.io?subject=Creating%20Organizations). We’re always here to help! # Members > Learn how to manage team members, permissions and ownership in Sliplane. You can invite other team members via email. Navigate to the [team member settings](https://sliplane.io/app/team) by clicking on “Team” in the left sidebar, or select “Team Settings” in the team dropdown menu inside the main navbar on top. From there, click on “Add Collaborator” and enter the email address of the user you want to invite. Pick the permissions the new member should have and click on “Send Invitation”. If the invitee does not have a Sliplane account yet, they will be asked to create one. Otherwise, they will get an invite email with a link to join your team. The email that you invited needs to match the primary Github email address of the invitee. ## Permissions [Section titled “Permissions”](#permissions) Every team has exactly one owner and any number of additional members. Members are granted individual permissions rather than a fixed role, so you can hand out exactly the access someone needs. Permissions are additive: a member with none can still read every resource in the team, and each permission you grant unlocks a specific set of actions on top of that. You can set permissions when inviting a collaborator and change them later from the member’s menu via “Edit Permissions”. | Permission | What it allows | | -------------------- | ---------------------------------------------------------------------------- | | Manage resources | Create, update and delete servers, services, projects, databases and buckets | | Manage collaborators | Invite and remove members, and edit their permissions | | Billing | View invoices and billing history, and download invoice PDFs | ### The owner [Section titled “The owner”](#the-owner) Each team has exactly one owner. The owner implicitly holds every permission and is the only member who can: * change team settings (like the team name) * access the compliance page and sign the DPA * transfer ownership of the team * delete the team The owner cannot have their permissions edited or be removed like a regular member. To change who owns a team, use an ownership transfer. ### The owner is responsible for billing [Section titled “The owner is responsible for billing”](#the-owner-is-responsible-for-billing) The owner is the billing owner of the team and is responsible for paying its invoices. This applies to every team you own, so if you own multiple teams you carry the billing responsibility for all of them. If invoices go unpaid, the team is restricted: after repeated failed payment attempts its services are suspended and its API keys are revoked until the outstanding balance is settled. Because you are the billing owner for every team you own, unpaid invoices are not contained to the team that owes them. As long as a balance stays outstanding, your other teams are also at risk of being restricted, so settle any unpaid invoice promptly. Because the owner carries this responsibility, a team must always have exactly one owner. ## Transferring ownership [Section titled “Transferring ownership”](#transferring-ownership) Ownership is handed over through a transfer that the recipient has to accept, so ownership never changes without both people agreeing to it. To start a transfer, open the [“Unsafe Territory”](https://sliplane.io/app/team/delete) page in your team settings, pick the collaborator you want to hand the team to, and click “Transfer ownership”. You will be asked to confirm by typing the team name. Only the current owner can start a transfer, the recipient has to be another active member, and there can only be one transfer pending at a time. A transfer is blocked while the team has open (unpaid) invoices. Settle any outstanding invoices first, otherwise the transfer cannot be started or accepted. A pending transfer expires 24 hours after you start it. If the recipient does not accept within that window the offer lapses on its own, ownership stays with you, and you can simply start a new transfer if you still want to hand the team over. Once started, the recipient sees a banner prompting them to accept or decline the transfer, along with how long they have left to accept. Ownership stays with you until they accept, and you can cancel the pending transfer at any point before that. When the recipient accepts: * they become the sole owner and take over billing responsibility for the team * you stay on the team as a full-permission member Accepting is not just a permission change. The new owner becomes the billing owner of the team: they are responsible for paying its invoices, and if invoices go unpaid the billing owners services can be suspended and its API keys revoked (see [The owner is responsible for billing](#the-owner-is-responsible-for-billing) above). Make sure the recipient understands this before they accept. You cannot undo a transfer yourself after it is accepted, so the new owner would have to transfer it back. > Personal teams (your default team) cannot have their ownership transferred. # Server Quotas > Learn about server creation limits and how to request increases. Sliplane uses a quota system to manage how many servers of each type you can create per team. Quotas are applied per server type and region. ## Viewing Your Quotas [Section titled “Viewing Your Quotas”](#viewing-your-quotas) You can view your current quotas in your [team’s settings](https://sliplane.io/app/team/quotas). If you’ve reached the limit for a specific server type, it will be indicated there and you can request the increase of quotas from here. ## Requesting a Quota Increase [Section titled “Requesting a Quota Increase”](#requesting-a-quota-increase) Some larger server types require a manual approval before you can create them. If you need more servers of a specific type than your current quota allows, you can request an increase: 1. Navigate to the server creation page 2. Select the server type you need 3. If the quota is reached or requires a request, you’ll see an option to request an increase 4. Provide a reason for the request and the quantity you need 5. Our team will review your request and get back to you Note Only one quota request per server type can be pending at a time. You’ll need to wait for a response before submitting another request for the same type or contact our support for more specific requirements. # Referral Program > Learn about Sliplane's referral program. Give 10€, Get 10€ - Referral Program When someone signs up for Sliplane through your referral link, they will receive 10€ in credits. As the referrer, you will receive 10€ in credits for each referred person who spends at least 10€ with us after their initial credits have been used. Your referral link can be found in your [team settings](https://sliplane.io/app/team/referral). All conditions to enter the referral program can be found [here](https://sliplane.io/referral). # Registry Credentials > Learn how to manage container registry credentials in Sliplane. Registry credentials are used to access private container registries. In Sliplane, your credentials are stored on team level, meaning everyone in the team can use them. Note All Credentials will be stored encrypted The credential contains: 1. The provider (see supported registries below) 2. A name to help you identify your credential 3. The username or namespace 4. A token or password ## Supported Registries [Section titled “Supported Registries”](#supported-registries) | Provider | Description | | ---------------------- | ------------------------------------------------------------------------------------------------ | | GitHub (GHCR) | GitHub Container Registry at `ghcr.io` | | Docker Hub | Docker Hub at `docker.io` | | Docker Hardened Images | Docker’s verified hardened images at `dhi.io` | | Generic | Any other container registry (e.g. AWS ECR, Google Artifact Registry, GitLab Container Registry) | Find out more information about how to create credentials for private images: * [Authenticating to GHCR](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry) * [Access tokens for Docker Hub](https://docs.docker.com/security/for-developers/access-tokens/) # Team Settings > Learn how to configure your Sliplane team settings. In the [team settings](https://sliplane.io/app/team/settings) you can change the name of your team. Just enter a new name inside the team name input field and hit save to update your settings.