Deploy Settings
Learn how to configure squadbase.yml for your dashboard deployments.
Squadbase uses a YAML configuration file to define how your dashboard should be built and deployed. When you specify build and cloud environment settings, they're automatically applied during deployment.
The file is typically saved as squadbase.yml, but you can customize the filename by changing the Setting file path in the dashboard.
The required configuration options vary depending on your runtime and framework.
version: '1'
build:
framework: streamlit
runtime: python3.11
package_manager: pip
entrypoint: app.py
deployment:
provider: gcp
gcp:
memory: 1Gi
cpu: 1
timeout: 300
concurrency: 80
min_instances: 0
max_instances: 10version: '1'
build:
framework: nextjs
runtime: node20
package_manager: npm
deployment:
provider: aws
aws:
memory: 512
timeout: 30
provisioned_concurrency: 0
ephemeral_storage: 512version: '1'
build:
framework: fastapi
runtime: python3.11
package_manager: pip
deployment:
provider: aws
aws:
memory: 512
timeout: 30
provisioned_concurrency: 0
ephemeral_storage: 512version: '1'
build:
framework: django
runtime: python3.11
package_manager: pip
deployment:
provider: aws
aws:
memory: 512
timeout: 30
provisioned_concurrency: 0
ephemeral_storage: 512version: '1'
build:
dockerfile: Dockerfile
context: .
build_args:
NODE_ENV: production
deployment:
provider: gcp
gcp:
memory: 1Gi
cpu: 1
timeout: 300
concurrency: 80Place your squadbase.yml in the root of your project's codebase.
Build
Configure build settings under the build: section.
Squadbase uses Docker to build your dashboards. For officially supported frameworks, you don't need to write your own Dockerfile—Squadbase provides one automatically. If you're using an unsupported framework or need to customize your environment (e.g., installing additional packages), you can provide your own Dockerfile.
Using an officially supported framework
When using a supported framework, configure the following settings:
| Key | Values | Description |
|---|---|---|
framework | streamlit nextjs fastapi django morph | Framework |
runtime | python3.9 python3.10 python3.11 python3.12 python3.13 node18 node20 node22 | Runtime |
package_manager | pip poetry uv npm yarn pnpm | Package manager |
entrypoint | src/app.py src/main.py src/index.py | App entry point |
The entrypoint setting is only used with Streamlit to specify the Python file to run. It's ignored for other frameworks.
When deploying with a supported framework, Squadbase provides the following capabilities:
- Invite-only cloud deployment
- Built-in user authentication
- User analytics
- Log monitoring
- User feedback collection
Using a custom Dockerfile
If a Dockerfile exists in your project root, Squadbase will use it instead of the framework-specific build settings.
You can also specify a custom Dockerfile path using the dockerfile key.
| Key | Type | Description |
|---|---|---|
dockerfile | string | Path to custom Dockerfile (e.g., docker/Dockerfile.prod) |
context | string | Build context directory (defaults to .) |
build_args | object | Build arguments to pass to Docker |
Example:
build:
dockerfile: docker/Dockerfile.prod
context: .
build_args:
NODE_ENV: production
API_KEY: ${API_KEY}When using a custom Dockerfile, the framework, runtime, package_manager, and entrypoint keys are ignored.
Deployment
Configure deployment settings under the deployment: section.
Use provider to specify your cloud provider. If not specified, aws is used by default.
Starting October 2025, the default provider for new projects has changed from gcp to aws. Existing projects are not affected. Streamlit projects will continue to use gcp as the default since AWS deployments don't support WebSocket connections, which Streamlit heavily relies on.
AWS
| Key | Type | Description |
|---|---|---|
memory | number | Memory (MB) |
timeout | number | Timeout (seconds) — max 900 |
provisioned_concurrency | number | Provisioned concurrency |
ephemeral_storage | number | Ephemeral storage (MB) |
GCP
| Key | Type | Description |
|---|---|---|
memory | string (e.g., 1Gi, 512Mi) | Memory |
cpu | number | CPU |
timeout | number | Timeout (seconds) — max 7 days (604800) |
concurrency | number | Max concurrent requests |
min_instances | number | Minimum instances |
max_instances | number | Maximum instances |
ephemeral_storage | string (e.g., 1Gi, 512Mi) | Ephemeral storage |
region | string | GCP region. Currently supports us-central1, asia-northeast1, and europe-west1. |
Region selection is not currently available for AWS deployments due to technical limitations. We plan to add this feature in the future.
Pricing
Runtime charges are based on three metrics: memory usage, request count, and CPU usage.
You're billed according to the compute specifications defined in your deployment settings.
GB-seconds and vCPU-seconds represent the cost of using 1 GB of memory or 1 vCPU for one second, respectively.
| Memory ($/GB-sec) | Requests ($/1M) | CPU ($/vCPU-sec) | |
|---|---|---|---|
| 1. AWS | $0.00002 | $0.25 | – |
| 2. AWS – Standby | $0.000005 | – | – |
| 3. GCP | $0.000003 | $0.50 | $0.000027 |
| 4. GCP – Standby | $0.000003 | – | $0.000027 |
Standby instances correspond to provisioned_concurrency on AWS and min_instances on GCP.
Enabling standby instances keeps your server running even when idle, reducing cold start latency.