Services

Slasha makes it easy to provision and attach managed backing services—such as relational databases, document stores, or in-memory caches—alongside your applications. Services run in secure, isolated containers on your server and are instantly network-accessible to your application containers.

Supported Services & Environment Variables

When you provision a backing service, Slasha auto-generates secure credentials, connection parameters, and configurations as environment variables on the service container. These variables, along with any custom environment variables you define for the service, are not automatically injected into your application containers. Instead, you must explicitly reference them in your application's environment variables using variable interpolation (e.g., DATABASE_URL=${{ db.DATABASE_URL }}). For more details, see Service Environment Variables.

Services also support variable interpolation within their own environment configurations, allowing them to reference other variables set on the service (e.g., ${{ PORT }}) or reference platform-level details under the SLASHA namespace (such as ${{ SLASHA.service_container_name }} or ${{ SLASHA.network_name }}). For a complete list of system keys available to services, see Service Environment Interpolation.

Below are the supported service types and the exact environment variables generated on the service container for each:

PostgreSQL

Managed relational database. Supported versions: 13, 14, 15, 16, 17

  • POSTGRES_USER
  • POSTGRES_PASSWORD
  • POSTGRES_DB
  • PORT
  • DATABASE_URL (e.g. postgres://user:password@host:port/dbname)

MySQL

Managed relational database. Supported versions: 8.0, 8.4, 9.0

  • MYSQL_USER
  • MYSQL_PASSWORD
  • MYSQL_DATABASE
  • MYSQL_ROOT_PASSWORD
  • PORT
  • DATABASE_URL (e.g. mysql://user:password@host:port/dbname)

MongoDB

Managed document database. Supported versions: 6.0, 7.0, 8.0

  • MONGO_INITDB_ROOT_USERNAME
  • MONGO_INITDB_ROOT_PASSWORD
  • MONGO_INITDB_DATABASE
  • PORT
  • DATABASE_URL (e.g. mongodb://user:password@host:port/dbname?authSource=admin)

Redis

Managed in-memory key-value cache and message broker. Supported versions: 7.0, 7.2, 7.4

  • REDIS_PASSWORD
  • PORT
  • DATABASE_URL (e.g. redis://default:password@host:port)

Data Volumes

Every backing service is allocated a persistent Docker volume to ensure stored data survives container restarts. The mount paths inside the service containers are:

  • PostgreSQL: /var/lib/postgresql/data
  • MySQL: /var/lib/mysql
  • MongoDB: /data/db
  • Redis: /data

Service Provisioning & Health Checks

When you provision or redeploy a backing service, Slasha pulls the required image and starts the container. It then waits for the service to become healthy. The health check timeout is 180 seconds; if the container does not report as healthy within this time, the provisioning fails and the container is stopped.

Restart vs Redeploy

When managing backing services, it's important to understand the difference between restarting and redeploying:

  • Restart: Stops the existing service container and starts it again. No configuration is changed.
  • Redeploy: Destroys the existing container and provisions an entirely new one using the current configuration (useful if you changed version or resources). Data volumes are preserved and automatically mounted to the new container.

Secure Tunnels

Backing services run inside private, isolated Docker networks and do not expose ports to the public internet. Slasha includes a secure proxy tunneling feature that allows you to connect directly to your backing services from your local machine. For commands and configuration details, see the slasha services proxy command reference.

Backups

Slasha supports exporting data dumps from your backing services. You can trigger and save these backups via the command line. For details, refer to the slasha services backup command reference.

Persistent StorageDomains & HTTPS