# Serverless Git Deployments

Deploy serverless containers directly from a Git repository. DanubeData clones your code, builds a container image, and deploys it automatically — with optional auto-deploy on every push.

## Supported providers

| Provider | Repository URL format | Webhook signature |
|----------|----------------------|-------------------|
| **GitHub** | `https://github.com/org/repo` | HMAC-SHA256 (`X-Hub-Signature-256`) |
| **GitLab** | `https://gitlab.com/org/repo` | Token comparison (`X-Gitlab-Token`) |
| **Bitbucket** | `https://bitbucket.org/org/repo` | HMAC-SHA256 (`X-Hub-Signature`) |

SSH-format URLs (`git@github.com:org/repo.git`) are also supported.

## Repository authentication

| Method | Use case |
|--------|----------|
| **None** | Public repositories |
| **SSH Key** | Private repos. Paste your SSH private key in the dashboard. |
| **Access Token** | Private repos. Use a personal access token with read permissions. |

For SSH keys, generate a deploy key with read-only access:

```bash
ssh-keygen -t ed25519 -f deploy_key -N ""
```

Add the public key (`deploy_key.pub`) to your repo's deploy keys. Paste the private key (`deploy_key`) in DanubeData.

For access tokens, create a token with repository read permissions in your Git provider's settings.

## Build methods

### Buildpacks (recommended)

Buildpacks auto-detect your application's runtime and build a container image without a Dockerfile. This is the easiest way to get started.

**Supported runtimes:**

| Runtime | Detection file(s) |
|---------|-------------------|
| **Node.js** | `package.json` |
| **Python** | `requirements.txt`, `setup.py`, `pyproject.toml`, `Pipfile` |
| **Go** | `go.mod`, `go.sum` |
| **Java** | `pom.xml`, `build.gradle`, `build.gradle.kts` |
| **Ruby** | `Gemfile`, `Gemfile.lock` |
| **PHP** | `composer.json`, `index.php` |
| **.NET** | `*.csproj`, `*.fsproj`, `*.sln` |
| **Rust** | `Cargo.toml` |

**Available builders:**

| Builder | Best for |
|---------|----------|
| **Paketo Base** | Java, Node.js, Python, Go, Ruby, .NET. Good default. |
| **Paketo Full** | Extended language support with more system libraries. |
| **Paketo Tiny** | Go applications. Produces minimal images. |
| **Google Cloud Buildpacks** | Node.js, Python, Go, Java. |
| **Heroku Builder 22** | Node.js, Python, Ruby, PHP, Go, Java. Familiar if coming from Heroku. |

### Dockerfile

Use your own Dockerfile for full control over the build.

**Configuration:**

| Setting | Default | Description |
|---------|---------|-------------|
| **Dockerfile path** | `Dockerfile` | Path to the Dockerfile relative to the repo root |
| **Build context** | `/` | Directory used as the Docker build context |

Example for a non-standard layout:

```
Dockerfile path: docker/Dockerfile.production
Build context: /
```

## Build pipeline

When a build is triggered (manually or via webhook), DanubeData runs a Tekton pipeline:

```
Clone Repository
      |
      v
Detect Runtime (Buildpacks)
      |
      v
Build Image (Buildpacks or Dockerfile)
      |
      v
Push to Registry (registry.danubedata.ro)
      |
      v
Deploy (Knative Service via GitOps)
```

### Build limits

| Limit | Value |
|-------|-------|
| **Build timeout** | 30 minutes |
| **Concurrent builds per team** | 3 |
| **Builds per day per team** | 50 |
| **Build log access** | 10 days after completion; history metadata is separate |

### Build statuses

| Status | Description |
|--------|-------------|
| **Pending** | Queued, waiting for build resources |
| **Cloning** | Fetching source code from the repository |
| **Building** | Building the container image |
| **Pushing** | Uploading the image to the registry |
| **Succeeded** | Build completed, deployment in progress |
| **Failed** | Build failed — check build logs |
| **Cancelled** | Build cancelled by user |

### Build actions

| Action | Description |
|--------|-------------|
| **Trigger Build** | Start a new build manually (from the Actions dropdown) |
| **Cancel** | Stop an in-progress build |
| **Retry** | Retry a failed build with the same configuration |
| **Redeploy** | Deploy a previously succeeded build without rebuilding |

## Webhooks

### Automatic setup

When you create a Git-deployed container, DanubeData generates:

- **Webhook URL** — The endpoint your Git provider should call on push
- **Webhook Secret** — Used to verify webhook signatures

Both are displayed in the **Activity** tab of the container detail page. (Builds and deployments now share this single tab.)

### Manual webhook setup

1. Copy the Webhook URL and Secret from the Activity tab
2. In your Git provider's repository settings, add a new webhook:

**GitHub:**
1. Go to Settings > Webhooks > Add webhook
2. **Payload URL** — Paste the webhook URL
3. **Content type** — `application/json`
4. **Secret** — Paste the webhook secret
5. **Events** — Select "Just the push event"

**GitLab:**
1. Go to Settings > Webhooks
2. **URL** — Paste the webhook URL
3. **Secret token** — Paste the webhook secret
4. **Trigger** — Check "Push events"

**Bitbucket:**
1. Go to Repository settings > Webhooks > Add webhook
2. **URL** — Paste the webhook URL
3. **Secret** — Paste the webhook secret
4. **Triggers** — Select "Repository push"

### Auto-build on push

When **auto-build on push** is enabled (default), every push to the configured branch triggers a new build and deployment.

To disable auto-build:
1. Navigate to the container **Edit** page
2. Uncheck **Auto-build on push**
3. Save

With auto-build disabled, you can still trigger builds manually from the dashboard or via the API.
Disabling it also prevents queued push-triggered jobs and deferred pushes from
starting a build. A build that has already started is allowed to finish; use
**Cancel** if you also need to stop that build.

## Build logs

View build logs from the **Activity** tab:

1. Navigate to the container detail page
2. Click the **Activity** tab
3. Click on a build to view its logs

Logs stream live as the build runs and refresh on their own, so you can watch progress in real time. You get the full build output — there is no line limit — across all stages: clone, build, and push.

Completed build output is available for ten days after completion. Expired output
cannot be fetched again through the console or API; hourly cleanup removes its
stored text while retaining build history metadata. This is a platform policy,
not a per-container setting. Keep sensitive information out of build output.

If a deploy fails, the container shows a plain-language reason with a hint on how to fix it — for example an architecture mismatch, an image or tag that can't be found, running out of memory, or a startup that timed out.

## Troubleshooting

### Build fails during clone

- Verify the repository URL is correct
- For private repos, check that your SSH key or access token has read permissions
- Ensure the branch exists in the repository

### Build fails during image build

- **Buildpacks:** Ensure your project has the correct detection files (e.g., `package.json` for Node.js)
- **Dockerfile:** Verify the Dockerfile path is correct and the file is valid
- Check build logs for specific error messages
- Ensure your application's dependencies can be resolved (no private package registries without credentials)

### Build succeeds but container fails to start

- Check that your application listens on the configured port (default: 8080)
- Verify environment variables are set correctly
- Check container logs from the detail page for runtime errors
- Ensure the container runs as non-root (UID 1000) — modify your Dockerfile if needed

### Webhook not triggering builds

- Verify the webhook URL and secret match exactly
- Check your Git provider's webhook delivery logs for errors
- Ensure the push is to the configured branch
- Confirm auto-build on push is enabled

## Next steps

- [Serverless overview](https://docs.danubedata.ro/serverless-overview) — Full feature documentation
- [Custom domains](https://docs.danubedata.ro/serverless-domains) — Add your own domain
- [Invoking containers](https://docs.danubedata.ro/serverless-invoking) — Code examples for calling your container

---

**Questions?** Contact support at support@danubedata.ro