Bucket Mounts, Web Terminal & GitHub Integration

Web Terminal

Ink now provides an interactive shell into any running service directly from the dashboard. No SSH keys, no port forwarding, no VPN — select a service and open a terminal.

The terminal uses a secure exec proxy that bridges the browser to the container runtime over an authenticated WebSocket connection. Sessions are scoped to the requesting user's workspace and authenticated against existing Ink credentials. The connection is encrypted in transit and subject to the same RBAC policies as all other workspace operations.

The terminal emulator is built on xterm.js with full ANSI color support, clickable URLs, and automatic viewport resizing. The session attaches to the container's default shell (bash, sh, or whatever your image provides).

Typical use cases include debugging a running service, inspecting the filesystem, tailing logs, running database migrations, or verifying environment variables. Sessions time out after 4 hours of inactivity and are limited to 5 concurrent sessions per user.

The exec endpoint is also exposed through MCP and the CLI, so agents can open a shell, execute commands, and inspect output programmatically:

ink exec ml-pipeline

Bucket Mounts

Services frequently require access to large datasets, model weights, or shared configuration stored in cloud object storage. Bucket mounts attach an S3, GCS, or Azure Blob Storage bucket to any service's filesystem as a local directory. S3-compatible providers (MinIO, Cloudflare R2, Backblaze B2, etc.) are also supported via a custom endpoint URL.

Select a sync mode that matches your workload:

How syncing works

Ink runs a lightweight sidecar container alongside your service that manages all synchronization. Your application reads and writes to the mount path as if it were a local directory — the sidecar handles transfers to and from the bucket transparently.

1. Store credentials — Add your cloud provider credentials (IAM access key, GCS service account, or Azure connection string) to the project. Credentials are encrypted at rest and never exposed to your application code.
2. Attach on deploy — Configure a bucket mount on any service with a mount path, sync mode, and optional key prefix to scope the mount to a subdirectory of the bucket.
3. Sidecar manages sync — On startup, the sidecar pulls the current bucket contents into the mount path. It then continues to pull changes from the bucket at the configured interval. In bidirectional mode, files your service writes to the mount path are also pushed back to the bucket continuously.

ink service create ml-pipeline \
  --repo ml-pipeline \
  --memory 2Gi \
  --vcpus 1 \
  --bucket training-data:/data \
  --bucket-mode bidirectional \
  --sync-interval 5

The mount path appears as a regular directory inside your container. Read parquet files, write checkpoints, serve model weights — your code does not need to know it is backed by object storage. Sync intervals are configurable per mount and default to 5 seconds.

Delegated GitHub Access

GitHub App installations are now scoped to workspaces. When you install the Ink GitHub App on a GitHub organization or user account, every member of the associated Ink workspace can deploy from the connected repositories.

This follows the same delegated authorization model used by Railway, Render, and Vercel: the GitHub App grants the platform access to your repositories, and the platform manages per-user authorization internally. Individual repository credentials are never shared between users.

What changed

Previously, GitHub App installations were tied to the user who created them. If Alice installed the app on the acme-corp organization, only Alice could deploy from those repositories. The installation is now bound to the workspace, so any workspace member can deploy from connected repositories under the platform's delegated access.

• Any workspace member can deploy from repositories connected to the workspace
• Manage installations per workspace from the settings page — add or revoke at any time
• Multiple workspaces can reference the same GitHub App installation independently
• Webhook-driven deploys — pushes to connected repositories trigger automatic redeployments for all services watching that repository

This is particularly useful for teams where both human developers and AI agents (Claude Code, Codex, etc.) deploy from the same repositories without requiring separate GitHub App installations.

Other Improvements

• Service rename — Rename a running service without redeploying. The previous URL continues to serve traffic for 24 hours with an automatic redirect.
• Project card overflow menu — Quick actions (rename, delete, settings) are now accessible from the project list without opening the detail page.
• Sync mode indicators — The bucket mount UI now displays the configured sync mode and interval alongside each mount.
• GraphQL schema updates — New queries and mutations for bucket credentials, exec sessions, and GitHub installations are available for direct API consumers.