Deployments & Builds

Slasha simplifies application deployment using a Git-centric workflow. Every time you push code to Slasha, it checks out the commit, automatically detects the correct build strategy, compiles your code into a Docker image, and orchestrates the deployment container lifecycle.

How Git Deployments Work

When you create an application, Slasha provisions a bare Git repository on your server. You deploy by adding this repository as a remote and pushing your code. Slasha supports two methods of authentication for Git pushes:

1. SSH Authentication

This is the recommended method. You add your public SSH key to the platform, and Slasha's built-in SSH server validates your push securely.

# add the remote
git remote add slasha git@your-server-domain:your-app-slug

# push to deploy
git push slasha main

Note: If you run Slasha inside Docker, the SSH server operates on port 2222 instead of 22. The remote URL should be: ssh://git@your-server-domain:2222/your-app-slug.

2. HTTPS Authentication

Alternatively, you can push over HTTPS using Basic Authentication. Use your Slasha account email as the username and your account password as the password.

# add the remote
git remote add slasha https://your-server-domain/your-app-slug.git

# push to deploy
git push slasha main

Once authenticated, Slasha pulls the commit into a temporary workspace and initiates the build pipeline.

Concurrent Build Guard

Slasha enforces a strict concurrent build guard: only one deployment build can run at a time per application. If you push code while a previous build is still in progress, the Git push itself will succeed (the code arrives in your repository), but the automatic deployment build will be skipped. You can manually trigger a deployment for that commit later.

Auto-Deploy

By default, pushing to the remote triggers an automatic deployment. If you want to push code without triggering a build, you can disable Auto-Deploy in the dashboard or via the CLI (see the CLI Apps Reference).

When auto-deploy is disabled, pushes just update the repository. You can then manually trigger a deployment from the dashboard or via the CLI when you are ready.

Deployment Lifecycle

A deployment progresses through several states during its lifecycle, which you can monitor via the CLI or dashboard:

Build Strategies

Slasha dynamically inspects your repository layout to determine the best build strategy. It supports two distinct build approaches:

1. Dockerfile Strategy

If your repository contains a Dockerfile in the root directory, Slasha compiles the application using Docker BuildKit. This provides maximum flexibility, allowing you to use multi-stage builds, customize your base OS, configure system packages, and declare custom volumes.

2. Railpack Strategy (Zero-Config Fallback)

If no Dockerfile is found in the project root, Slasha automatically falls back to Railpack. Railpack inspects your source code files to determine the programming language and framework (e.g. Node, Python, Ruby, Go, Rust, Java, etc.) and generates an optimized build plan without any manual configuration.

Container Port & Volume Resolution

After your application's Docker image is built, Slasha determines how to route network traffic to the container and where to mount persistent storage.

Container Port Resolution

Slasha needs to know which internal port your application's web process listens on so Caddy can forward incoming HTTP traffic to it. The resolution follows a strict priority order:

1. User-Defined PORT Variable: Slasha checks if you have explicitly defined a PORT environment variable for the app. If set, this takes absolute precedence.
2. Dockerfile EXPOSE Instruction: If no custom PORT variable exists, Slasha reads your Dockerfile and searches forEXPOSE instructions (e.g., EXPOSE 3000).
3. Fallback Default: If no environment variable is set and no EXPOSE instruction is found (including all Railpack builds), Slasha defaults to port8080.

For managing environment variables, see the Environment Variables Reference.

Persistent Storage Volumes

Every application is automatically allocated a default persistent storage volume mounted at /data, exposed under the SLASHA_DATA_DIR environment variable.

If your application requires custom volume paths, they must be explicitly declared in a Dockerfile using the VOLUME instruction. For a detailed guide on how volume allocation works and how to set up custom mounts, refer to the Persistent Storage Reference.

Application Metrics

Once your app is running, Slasha automatically collects runtime metrics directly from the Docker daemon. You do not need to install any agents in your containers.

• CPU usage (percentage relative to available cores)
• Memory usage (in bytes)
• Network I/O (bytes sent and received)
• Disk I/O (bytes read and written)

Metrics are sampled every 10 seconds and are retained on the server for 7 days. You can view these metrics in real-time by visiting the Metrics tab for your application in the dashboard.

Managing Deployments

Once deployed, you can control your active deployments using the dashboard or via terminal command utilities:

• Stop: Halts the running container instances of an application. Note that persistent data volumes are preserved.
• Restart: Stops and starts all processes under the current active deployment in a clean sequence.
• Redeploy: Triggers a fresh build of the current commit, pulling dependencies and compiling the app again.

To trigger these management operations via the command line, check out the CLI reference pages: slasha deploy and slasha services.