# Serverless | Sentry for Zap

### [Source Context](https://docs.sentry.io/platforms/go/guides/zap/usage/serverless.md#source-context)

`sentry-go` SDK comes with the support for serverless solutions out of the box. However, to get the source contexts right, you need to bundle your source code with the binary itself.

For example, when using **AWS Lambda** and given this tree structure:

```bash
.
├── bin
│   └── upload-image
│   └── process-image
│   └── create-thumbnails
├── functions
│   └── upload-image
│       └── main.go
│   └── process-image
│       └── main.go
│   └── create-thumbnails
│       └── main.go
├── helper
│   ├── foo.go
│   └── bar.go
├── util
│   ├── baz.go
│   └── qux.go
```

You can build one of the binaries and bundle them with the necessary source files with this command:

```bash
GOOS=linux go build -o bin/upload-image functions/upload-image/main.go && zip -r handler.zip bin/upload-image functions/upload-image/ helper/ util/
```

The only requirement is that you locate the source code on the deployed machine. Everything else should be done automatically by the SDK.

### [Events Delivery](https://docs.sentry.io/platforms/go/guides/zap/usage/serverless.md#events-delivery)

Most (if not all) serverless solutions won't wait for network responses before closing the process. Because of that, we need to make sure that the event is delivered to Sentry's servers.

It can be achieved twofold, using the [`sentry.Flush` method](https://docs.sentry.io/platforms/go/guides/zap/configuration/draining.md) or by swapping the transport to [`HTTPSyncTransport`](https://docs.sentry.io/platforms/go/guides/zap/configuration/transports.md#httpsynctransport).
