
Here at Dagger, we are on a mission to make your CI/CD pipelines programmable in the language of your choice. In the last few weeks, we have made great progress towards that goal by releasing SDKs for [Go](https://dagger.io/blog/go-sdk), [Python](https://dagger.io/blog/python-sdk), [Javascript and Typescrip](https://dagger.io/blog/nodejs-sdk)t in rapid succession. So rapid in fact, that some of you wondered how exactly we managed to pull it off!

[![Tweets](/img/screen-shot-2022-11-30-at-1.15.40-pm.png "Tweet References")](https://twitter.com/felipecruz/status/1593297610919628800)

Here’s the answer: we were cheating. Our SDKs don’t actually run your pipelines! Instead they send pipeline definitions to the Dagger Engine, which runs them and returns the result in a language-agnostic way.

Under the hood, we use a powerful API technology called [GraphQL](https://graphql.org/). And as of today, **so can you**. We are excited to publicly release the Dagger GraphQL API: a unified interface for programming the Dagger Engine using any standard GraphQL client.

[![GraphQL diagram](/img/dagger_graphql-diagram_01.png "Where the GraphQL API fits in the Dagger architecture")](https://docs.google.com/document/d/1QOG3ydXjfj9zA6W09ENecvAQvUiTEuDRVPPpT-PEOrA/edit#)

This release includes:

- [API documentation](https://docs.dagger.io/api), including guides, examples and a complete reference.
- An [API playground](https://play.dagger.cloud/) to run pipelines straight from your browser!
- A [new CLI](https://docs.dagger.io/cli) to run pipelines directly from the command-line

![playground gif](/img/solomon-playground-short.gif "Run CI/CD pipelines straight from your browser with the Dagger API playground!")

#### What does this mean for me?

First, and most importantly, if you are currently using a Dagger SDK, you can safely ignore this announcement and continue using Dagger exactly as before.

However, this release creates exciting new possibilities for the Dagger platform:

1. **Developers** can now use Dagger to program their CI/CD pipelines in over 20 languages, thanks to [GraphQL’s large and growing list of client implementations](https://graphql.org/code/#language-support). Note that the experience of using a standard GraphQL client is not the same as an official Dagger SDK. This is because “vanilla” clients follow the current state of the art in GraphQL development, which requires developers to write their queries manually (ideally with the help of an [interactive playground](https://play.dagger.cloud)). Dagger SDKs on the other hand automatically generate client libraries to hide the underlying GraphQL language, for a more native and polished experience. Developers that already know and love GraphQL may prefer the “vanilla” method; others will prefer official SDKs when they are available. Besides the aesthetic preferences, both are equally robust and full-featured. Going forward, we will continue to expand the list of available SDKs, and make it easier for the community to contribute new SDKs.
2. **Devops engineers** can use the new CLI to [run pipelines on-the-fly from the terminal or a shell script](https://docs.dagger.io/cli/389936/run-pipelines-cli). This can be used for experimentation, troubleshooting, and to retrofit Dagger pipelines into any system that can run shell commands, including: Makefiles, Jenkinsfiles, Github workflows, Gitlab pipelines, CircleCI configurations, Ansible playbooks, and many more.
3. There are many ways to develop a Dagger pipeline, but only one way to run them: by sending GraphQL queries to the Dagger Engine. This gives **infrastructure engineers** a natural insertion point to control every aspect of how pipelines are run, regardless of how they were developed. Whether it’s engine provisioning, logging, monitoring, authentication, authorization, networking, artifact management, or any other aspect of a robust and secure CI infrastructure: Dagger’s architecture allows for all of it to be configured or overridden by the operator. This will be the primary focus of our roadmap in the coming weeks.

#### Why GraphQL?

Engineers are generally not known for agreeing on things - we like to argue! But one thing we all seem to agree on is that the CI/CD experience is often frustrating, and should be improved. But how?

![yaml test](/img/ga-actions.png "yaml test")

We believe the answer is to decouple pipeline _logic_ from pipeline _infrastructure_, which in turn allows decoupling the concerns of application and infrastructure teams. This can be achieved with a powerful architectural pattern called the [hourglass model](https://arxiv.org/pdf/1607.07183.pdf): the same pattern that enabled the Internet, Unix, and more recently, Docker.

To apply the hourglass pattern to CI/CD we need an API expressive enough to connect the two parts of the hourlgass: run any pipeline logic, on any pipeline infrastructure - and do it well.

That is where GraphQL comes in. GraphQL is a perfect fit for the CI/CD “hourglass”, for three reasons:

1. **Technical**: GraphQL is fundamentally a graph traversal language. And it turns out that pipeline execution is fundamentally a graph traversal problem - it’s no coincidence that “Dagger” starts with “[DAG](https://en.wikipedia.org/wiki/Directed_acyclic_graph)”! Our early prototypes ended up looking so much like GraphQL, that it quickly became obvious that we should just build on top of it instead of reinventing the wheel.
2. **Human:** GraphQL was designed to decouple concerns between frontend and backend teams, by enabling frontend teams to compose queries themselves from building blocks provided by the backend team. Meanwhile, Dagger seeks to decouple concerns between application and infrastructure teams, by enabling application teams to compose pipelines themselves from building blocks provided by the infrastructure team. In both case, decoupling of concerns allows everyone to be happier and more productive.
3. **Ecosystem**: no one company can solve this problem alone. We are already standing on the shoulders of giants by leveraging the container ecosystem. Thanks to the GraphQL ecosystem we are now standing on the shoulders of TWO GIANTS! Every time anyone in the GraphQL and container ecosystem solves a problem for themselves, they are also solving it for everyone in the Dagger ecosystem.

Ready to give it a try? You can follow our [introduction guide](https://docs.dagger.io/api/254103/build-custom-client), browse the [API reference](https://docs.dagger.io/api/reference/), or [experiment with the API playground](https://play.dagger.cloud).

As always, we love hearing from you, let us know how you enjoy using the API, and what cool things you build with it.

Happy coding!


Introducing the Dagger GraphQL API

Today we are proud to introduce the [Node.js SDK](https://docs.dagger.io/sdk/nodejs): a new way to develop your CI/CD pipelines as code and run them anywhere.\
​

**The Dagger Node.js SDK may be a good fit if you are...**

* A front-end or back-end end developer wishing your CI pipelines were TypeScript or JavaScript code that you can run locally in seconds, instead of YAML that can only run on a proprietary service
* A developer who needs CI/CD, and is looking for an excuse to learn TypeScript or JavaScript
* Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful
* A platform engineer writing custom TypeScript tooling, with the goal unifying continuous delivery across organizational silos

This is our third SDK release in the past month, after [Go](https://dagger.io/blog/go-sdk) and [Python](https://dagger.io/blog/python-sdk). Our ultimate goal is to ensure all developers can develop their CI/CD pipelines in the same way they develop the rest of their code. If you are looking for a different SDK, [let us know](https://blocklayer.typeform.com/to/a6m5gKSS?). You can also subscribe to **[our newsletter](http://eepurl.com/hzIma5)** to be notified of future SDK launches.

**What is Dagger again?**

Dagger is a programmable CI/CD engine that runs your pipelines in containers.

**Programmable:** develop your CI/CD pipelines as code, in the same programming language as your application.

**Runs your pipelines in containers:** Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). This has several benefits:

* Instant local testing
* Portability: the same pipeline can run on your local machine, a CI runner, a dedicated server, or any container hosting service.
* Superior caching: every operation is cached by default, and caching works the same everywhere
* Compatibility with the Docker ecosystem: if it runs in a container, you can add it to your pipeline
* Cross-language instrumentation: teams can use each other’s tools without learning each other’s language

![diagram](/img/screen-shot-2022-10-25-at-9.22.41-am.png "diagram")

### **Dagger Node.js in Action**

In this demo, we’ll show you how to create a CI tool to test your Node.js application against multiple Node.js versions.

<iframe width="90%" height="400px" src="https://www.youtube.com/embed/cuqmq_aTNfY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

**Want to try it yourself? Check out our [Getting Started Guide](https://docs.dagger.io/sdk/nodejs/783645/get-started).** 

##### **Want to Get Involved?**

We have lots of ways to contribute and stay engaged with Dagger updates. We look forward to seeing you in our community forum:

* Join us on [Discord](https://discord.gg/dagger-io)
* [Report an issue or tell us about your use case](https://github.com/dagger/dagger/issues/new/choose)
* Join our weekly community call or meet up with us at an event. Check out the [events page](https://dagger.io/events) to see the latest!

Introducing the Dagger Node.js SDK

Today we are proud to introduce the [Dagger Python SDK](https://docs.dagger.io/sdk/python): a new way to develop your CI/CD pipelines as code and run them anywhere.

​
**The Dagger Python SDK may be a good fit if you are...**

* A Python developer wishing your CI pipelines were Python code that you can run locally in seconds, instead of YAML that can only run on a proprietary service
* A developer who needs CI/CD, and is looking for an excuse to learn Python
* Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful
* A platform engineer writing custom Python tooling, with the goal of unifying continuous delivery across organizational silos
* A data engineer looking to better integrate with your organization's CI/CD pipelines.

Just two weeks ago we announced the [Dagger Go SDK](https://docs.dagger.io/sdk/go), and will continue to release more SDKs in the future. Our ultimate goal is to ensure all developers can develop their CI/CD pipelines with the language of their choice, and enjoy all the benefits of running them with Dagger.

If you are looking for a different SDK, let us know by [filling this form](https://blocklayer.typeform.com/to/a6m5gKSS?typeform-source=deploy-preview-1019--dagger-io.netlify.app). We will notify you when your SDK is ready.

**What is Dagger again?**

Dagger is a programmable CI/CD engine that runs your pipelines in containers.

**Programmable:** develop your CI/CD pipelines as code, in the same programming language as your application.

**Runs your pipelines in containers:** Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). This has several benefits:

* Instant local testing
* Portability: the same pipeline can run on your local machine, a CI runner, a dedicated server, or any container hosting service.
* Superior caching: every operation is cached by default, and caching works the same everywhere
* Compatibility with the Docker ecosystem: if it runs in a container, you can add it to your pipeline
* Cross-language instrumentation: teams can use each other’s tools without learning each other’s language

![Diagram](/img/screen-shot-2022-10-25-at-9.22.41-am.png "Diagram ")

### **Dagger Python SDK in Action**

In this demo, we’ll show you how to create a CI tool to test your Python application against multiple Python versions.

<iframe width="90%" height="400px" src="https://www.youtube.com/embed/c0bLWmi2B-4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

**Want to try it yourself? Check out our [Getting Started Guide](https://docs.dagger.io/sdk/python/628797/get-started).** 

##### **Want to Get Involved?**

We have lots of ways to contribute and stay engaged with Dagger updates. We look forward to seeing you in our community forum:

* Join us on [Discord](https://discord.gg/dagger-io)
* [Report an issue or tell us about your use case](https://github.com/dagger/dagger/issues/new/choose)
* Join our weekly community call or meet up with us at an event. Check out the [events page](https://dagger.io/events) to see the latest!

Develop your pipelines as code with the Dagger Python SDK

As you might have seen, we released the [Dagger Go SDK 0.3.0](https://dagger.io/blog/go-sdk) early last week. Thanks to your many questions and suggestions, we were able to ship several additional improvements, which we are releasing today as the Dagger Go SDK 0.4.0.

Note that this version introduces a breaking API change. However, we believe the improved API allows you to write much shorter code, which is significantly better in the long run.

**[Get Started](https://docs.dagger.io/sdk/go)** 

### Dagger Go SDK 0.4 Highlights:

#### Multi-platform pipelines

* Dagger now supports pulling container images and executing commands on platforms that differ from the underlying host.
* For example, you can use Dagger to compile binaries that target different CPU architectures, test those binaries and push them to a registry bundled as a multi-platform container image, all on a single host. 

**[Learn more about Dagger’s multi-platform support](https://docs.dagger.io/sdk/go/406009/multiplatform-support/)**

#### Improved filesystem API

* Import any directory from the host filesystem with `Host.Directory.` This replaces the more cumbersome LocalDirs, `Host.Workdir` and `HostDirectory.Read`
* Export any directory to the host filesystem with `Directory.Export`. This replaces `HostDirectory.Write` 
* Export any file to the host filesystem with `Directory.Export`
* Export any container to an OCI archive on the host filesystem with `Container.Export`. 
* `Host.Directory`, `Host.Workdir`, and `Directory.WithDirectory` now support `include:/exclude:` params for filtering the set of files to select.

**[See more examples of working with the host filesystem](https://docs.dagger.io/421437/work-with-host-filesystem/)**

#### Less boilerplate

You no longer need to pass IDs, which makes the code you need to write much shorter. See the example below: 

Before: 

```
modules := c.Directory()
for _, f := range []string{"go.mod", "go.sum", "sdk/go/go.mod", "sdk/go/go.sum"} {
	fileID, err := workdir.File(f).ID(ctx)
	if err != nil {
		return err
	}

	modules = modules.WithCopiedFile(f, fileID)
}
```

After: 

```
modules := c.Directory()
for _, f := range []string{"go.mod", "go.sum", "sdk/go/go.mod", "sdk/go/go.sum"} {
	modules = modules.WithCopiedFile(f, workdir.File(f))
}
```

**[Read the API documentation](https://pkg.go.dev/dagger.io/dagger)**

### New Documentation

Along with the new release, we’ve added four [guides](https://docs.dagger.io/sdk/go/275922/guides/) to our [documentation](https://docs.dagger.io/) that answer the most common questions we’ve heard in the days following the initial release. We hope these guides will help you make the most of the Go SDK.

* [Work with the Host Filesystem](https://docs.dagger.io/421437/work-with-host-filesystem/): This guide explains how to interact with the host filesystem using the Go SDK. It includes code examples of setting the working directory on the host, mounting a host directory in a container, exporting a directory from a container to the host, and more.
* [Understand Multi-Platform Support](https://docs.dagger.io/sdk/go/406009/multiplatform-support/): This guide demonstrates different techniques to build applications for multiple platforms using the Go SDK. It includes code examples of building multi-platform applications using emulation and cross-compilation.
* [Copy Embedded Directories into a Container](https://docs.dagger.io/110632/embed-directories/): This guide explains how to copy an entire directory tree from a host to a container.
* [Use Dagger with Private Git Repositories](https://docs.dagger.io/sdk/go/710884/private-repositories/): You can use `ssh-add` to securely authenticate your Dagger Go CI pipeline against private Git repositories.This guide shows you how. 

Thank you to the Dagger Community for your continuous and quick feedback through our **[Discord channel](https://discord.com/invite/dagger-io)** and **[GitHub issues](https://github.com/dagger/dagger/issues/new/choose)**. We look forward to releasing more features and documentation soon! 

Are you looking for updates on a different SDK? Fill out this **[form](https://blocklayer.typeform.com/to/a6m5gKSS?typeform-source=dagger.io)**, and we will notify you when your SDK is ready. 

Do you have feedback on our documentation? Would you like to suggest a new guide? Send us your feedback and ideas in our **[Discord channel](https://discord.com/invite/dagger-io)** or **[open a new issue on GitHub](https://github.com/dagger/dagger/issues/new?assignees=&labels=area%2Fdocumentation&template=documentation.yaml).**

Dagger Go SDK 0.4: multi-platform, improved filesystem API and more

Today we are proud to introduce the [Dagger Go SDK](https://docs.dagger.io/sdk/go): a new way to develop your CI/CD pipelines as code and run them anywhere.[​](https://devel.docs.dagger.io/8g34z/get-started-sdk-go/#who-is-it-for)

**The Dagger Go SDK may be a good fit if you are...**

* A Go developer wishing your CI pipelines were Go code that you can run locally in seconds, instead of YAML that can only run on a proprietary service
* A developer who needs CI/CD, and is looking for an excuse to learn Go
* Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful
* A platform engineer writing custom Go tooling, with the goal unifying continuous delivery across organizational silos
* A cloud-native developer advocate or solutions engineer, looking to demonstrate a complex integration on short notice

**The Dagger Go SDK may not be a good fit if you are...**

* A developer who doesn't know Go, and is not interested in learning it. If you are looking for another SDK, let us know [here](https://blocklayer.typeform.com/to/a6m5gKSS). We will notify you when your SDK is ready.
* A "designated devops person" who doesn't think of themselves as a developer - nothing makes you happier than a battle-hardened shell script.
* Someone who loves programming in YAML, thank you very much.
* A container skeptic: the less containers are involved, the happier you are.

In the future, we will release more SDKs. Our ultimate goal is to ensure all developers can develop their CI/CD pipelines in the same way they develop the rest of their code. If you are looking for a different SDK, [let us know](https://blocklayer.typeform.com/to/a6m5gKSS?typeform-source=deploy-preview-1019--dagger-io.netlify.app). If you fill out the form, we will notify you when your SDK is ready!

**What is Dagger again?**

Dagger is a programmable CI/CD engine that runs your pipelines in containers.

**Programmable:** develop your CI/CD pipelines as code, in the same programming language as your application.

**Runs your pipelines in containers:** Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). This has several benefits:

* Instant local testing
* Portability: the same pipeline can run on your local machine, a CI runner, a dedicated server, or any container hosting service.
* Superior caching: every operation is cached by default, and caching works the same everywhere
* Compatibility with the Docker ecosystem: if it runs in a container, you can add it to your pipeline
* Cross-language instrumentation: teams can use each other’s tools without learning each other’s language

![Dagger Diagram ](/img/screen-shot-2022-10-25-at-9.22.41-am.png "Dagger Diagram ")

#### Dagger Go SDK in Action

In this demo, you will see how quickly you can create a Go CI tool that builds a Go application with multiple architectures and Go versions using the Dagger Go SDK.

<iframe width="90%" height="400px" src="https://www.youtube.com/embed/GgMskf-znh4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

**Want to try it yourself? Check out our [Getting Started Guide](https://docs.dagger.io/sdk/go/).**

##### **Want to Get Involved?**

We have lots of ways to contribute and stay engaged with Dagger updates. We look forward to seeing you in our community forum:

* Join us on [Discord](https://discord.gg/dagger-io)
* [Report an issue or tell us about your use case](https://github.com/dagger/dagger/issues/new/choose)
* Join our weekly community call or meet up with us at an event. Check out the [events page](https://dagger.io/events) to see the latest!  


Your CI pipelines should be code: introducing the Dagger Go SDK

A few days after [launching the public beta of Dagger](https://dagger.io/blog/public-launch-announcement), we asked the community a simple question: [how can we improve our developer experience](https://github.com/dagger/dagger/discussions/2052)? The most popular request was for a [VS Code](https://en.wikipedia.org/wiki/Visual_Studio_Code) extension with proper [Language Server](https://en.wikipedia.org/wiki/Language_Server_Protocol) integration. So we took the community's advice and got to work.

Today, we're happy to introduce the first version of [Dagger for VS Code](https://marketplace.visualstudio.com/items?itemName=Dagger.dagger), bringing a first-class Dagger development experience straight to one of the world's most popular IDE. We're also open-sourcing [our LSP implementation for CUE](https://github.com/dagger/cuelsp), so that every other IDE and text editor can benefit from an improved CUE development experience as well. For example, here is a [guide for adding CUE LSP support to vim](https://github.com/dagger/cuelsp/blob/main/docs/vim.md).

#### Features

For the first release, Dagger for VS Code includes three features: *jump to definition*; *hover*; and *syntax highlighting*. All three features can be used from other IDEs, using the [cuelsp implementation](https://github.com/dagger/cuelsp).

##### Jump to Definition

![Jump to Definition Example](/img/jump-to-def.gif)

Now, we have a simple way to explore the [Dagger Universe](https://universe.dagger.io) and all its definitions. The Dagger Universe is a collection of reusable components, so we can use the “go to definition” feature to pick the one you need quickly.

##### Hover

![Hover Example](/img/hover.gif)

You will need a basic understanding of [CUE definitions](https://cuetorials.com/overview/foundations/#definitions) to get the most out of Dagger. To decrease the learning curve, we have added the ability to show references inline. This provides an easy way to see the overall description of an action and its internal type.

When using “go to definition” and “show definitions”, you will have a complete overview of all CUE definitions used in your Dagger project.

##### Syntax highlighting

We took inspiration from the Golang syntax to create our LSP theme so you can find the essential information quickly.

![lsp theme](/img/lsp-theme.png)

#### What’s an LSP?

A Language Server Protocol (LSP) is a standard used between an editor and a language server to provide language-specific features like auto(completion), go to definition, show references, etc. An LSP is a developer's best friend since it enables an easier way of exploring and understanding code libraries, directly from your code editor:

![LSP Example](/img/buildkit-schema-2-1-.png)

#### The CUE LSP challenge

Creating a CUE language server differs from standard languages like Golang, Python, or C++. In a typical language server, you work directly with the files and interpret them to provide language features.

With CUE, it’s the same, but you also need to work with the CUE engine to compile CUE values to simplify the implementation further.

When creating the Dagger CUE LSP, this constraint added a layer of complexity that we addressed by building a multi-component architecture. We decided to split the responsibility of file loading, jump to definition, hover, etc., into small pieces of code so we can extend it with new features later.

This resulted in the architecture below:

![Dagger CUE LSP Architecture](/img/lip-architecture-1-.png)

#### What’s next?

If you're using VS Code, give [the Dagger extension](https://marketplace.visualstudio.com/items?itemName=Dagger.dagger) a try! If you are using vim, [follow our CUE LSP setup guide](https://github.com/dagger/cuelsp/blob/main/docs/vim.md).

We love hearing from you! To give us feedback, you can [start a discussion](https://github.com/dagger/dagger/discussions), [create an issue](https://github.com/dagger/dagger/issues/new/choose), or [join our Discord server](https://discord.gg/ufnyBtc8uY).


Introducing Dagger for VS Code with CUE LSP support


There’s a running joke in the developer community that the physical supply chain–the one moving goods around the globe– is far more efficient than the software supply chain. And with essentially all computing moving to the cloud, software supply chains are growing in size and complexity. Devops engineers tasked with automating them are under increasing pressure to break through the bottleneck.

My co-founders [Sam Alba](https://twitter.com/sam_alba), [Andrea Luzzardi](https://twitter.com/aluzzardi) and I had seen the same problem time and time again: burned out devops teams trying their hardest to cobble together deployment pipelines that are nearly impossible to scale or port to other cloud platforms. The app deployment experience is painful, and solving this problem is the holy grail of devops.

This is the problem that we aspire to solve with Dagger. Devops engineers using Dagger get a standardized set of building blocks that they can assemble any way they want, knowing that the result will run reliably on any cloud. We’ve been working with some of the best engineers in the world to develop the platform and are [excited to launch the public beta version today](https://dagger.io/blog/public-launch-announcement).

And we’re just getting started. Today, we also announce the closing of a $20 million Series A investment led by Redpoint Ventures, with participation from Y Combinator, Nat Friedman (former CEO, Github), Brian Stevens (former CTO, Google Cloud and former CTO, Red Hat), Idit Levine (founder and CEO, solo.io), Julius Volz (creator of Prometheus), Ellen Pao (former CEO, Reddit), Daniel Lopez (co-founder, Bitnami), and others. Erica Brescia at Redpoint will be an invaluable asset as the newest addition to our board. Erica has been a leader in the devops space for over a decade, as the former co-founder of Bitnami (acquired by VMWare) and former COO of GitHub. We couldn’t imagine a better partner to build an industry-defining platform business.

We would also like to take the opportunity to thank [New Wave](https://newwave.vc), who led our $7 million seed funding round last year. As European founders we are proud to count a European fund as one of our major investors, proof that excellence in venture capital has no borders. Our total funding raised now amounts to $30 million, and we’re thrilled to keep growing our team and developing the Dagger platform with the open source community.

If you or anyone you know wants to join the team building the next stage of the devops revolution, [we would love to chat](https://dagger.io/careers).


Introducing the Dagger GraphQL API

Introducing the Dagger GraphQL API

Introducing the Dagger Node.js SDK

Develop your pipelines as code with the Dagger Python SDK

Dagger Go SDK 0.4: multi-platform, improved filesystem API and more

Your CI pipelines should be code: introducing the Dagger Go SDK

Introducing Dagger for VS Code with CUE LSP support

Announcing our $20M Series A from Redpoint Ventures