# EGo: running a Go binary inside an Intel SGX enclave

> EGo is a Go SDK for confidential computing that compiles ordinary Go programs into Intel SGX enclaves with an adapted compiler and a CLI for signing and running them. The value is in hiding the enclave plumbing behind a normal build and run workflow, and the price is Intel SGX hardware, an attested host, and a workflow that a container alone cannot give you.

**edgelesssys/ego** — EGo is an open-source SDK that enables you to develop your own confidential apps in the Go programming language.

- Repository: https://github.com/edgelesssys/ego
- Website: https://www.edgeless.systems/products/ego/
- Stars: 596 · Forks: 56
- Language: Go
- License: MPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/edgelesssys-ego

## Two tools standing in for a compiler and a loader

EGo is a framework for building confidential apps in Go. Confidential apps run in always-encrypted and verifiable enclaves on Intel SGX enabled hardware, and EGo's job is to make enclave development less painful than writing the enclave plumbing yourself.

It does that with two tools, and the split explains most of how the project feels in use. `ego-go` is an adapted Go compiler that builds enclave-compatible executables from a given Go project, while providing the same CLI as the original Go compiler. `ego` is a CLI tool that handles all enclave-related tasks such as signing and enclave creation.

That division is the design idea. The compiler side is a fork rather than a plugin, because producing something the enclave loader will accept requires a different code generation path, not a wrapper script. The `ego` side is where the trust boundary sits: signing is what binds a binary to a measurement that a remote party can later verify, and creation is what produces the artefact the host runs.

The result is a three step workflow that reads like a normal Go build:

```sh
ego-go build hello.go
ego sign hello
ego run hello
```

The compiler is the ordinary Go compiler with the same flags, so build tags, module handling and the rest of the toolchain work as a Go developer expects. What changes is the output: an executable that is a host program plus an enclave rather than a plain program.

The audience is narrow and specific. Anyone who wants to run their own code on a remote machine without the operator being able to read it, and who has decided that hardware based confidentiality is the right answer.

## Attestation is the part you cannot skip

A confidential enclave is only useful if a client can check what is running. That check is remote attestation, and EGo exposes it through a dedicated API rather than expecting every project to roll its own.

The samples directory shows the range of what is available. The remote_attestation sample shows how to use the basic remote attestation API. The attested_tls sample is similar but uses a higher level API to establish an attested TLS connection, which is the version most applications will want, since it removes the need to write the challenge and response exchange by hand. There is also an azure_attestation sample showing how to use Microsoft Azure Attestation for remote attestation, and a local_attestation sample in the tree.

The EGo API documentation on pkg.go.dev is described as providing access to remote attestation and sealing to a confidential app at runtime. Sealing is the other half of the confidential computing model: data encrypted inside the enclave can only be decrypted by that same enclave on that same machine, which is what makes persistent state possible without a key sitting in the clear.

EStore is the companion piece for that. The estore sample shows how to securely persist data using EStore, and the README points at the EStore project as the way to securely persist an application's data.

The practical point for an adopter is that attestation is not an optional extra you can skip for internal deployments. An enclave that nobody verifies is just an encrypted process, and the whole guarantee rests on the client deciding whether to trust what is running.

## Three ways to install, one of them a Docker build

The easiest installation is the snap:

```sh
sudo snap install ego-dev --classic
```

That needs gcc and libcrypto alongside it, and on Ubuntu the README gives the package command:

```sh
sudo apt install build-essential libssl-dev
```

If you are on Ubuntu 20.04, 22.04 or 24.04 there is a DEB package instead, and the install is a longer sequence because it also adds the Intel SGX repository:

```bash
sudo mkdir -p /etc/apt/keyrings
wget -qO- https://download.01.org/intel-sgx/sgx_repo/ubuntu/intel-sgx-deb.key | sudo tee /etc/apt/keyrings/intel-sgx-keyring.asc > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/intel-sgx-keyring.asc arch=amd64] https://download.01.org/intel-sgx/sgx_repo/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/intel-sgx.list
sudo apt update
EGO_DEB=ego_1.10.1_amd64_ubuntu-$(lsb_release -rs).deb
wget https://github.com/edgelesssys/ego/releases/download/v1.10.1/$EGO_DEB
sudo apt install ./$EGO_DEB build-essential libssl-dev
```

Building from source needs Edgeless RT installed and sourced, then a plain CMake sequence:

```sh
mkdir build
cd build
cmake ..
make
make install
```

The Docker route is the one to reach for if you want a reproducible artefact, and the README frames it that way. Building the latest release:

```sh
cd dockerfiles
DOCKER_BUILDKIT=1 docker build --target export -o. - < Dockerfile
```

The build produces the DEB package for Ubuntu 22.04, and for Ubuntu 20.04 you swap in `Dockerfile.focal`. Two further targets build the `ego-dev` and `ego-deploy` images from the same file:

```sh
DOCKER_BUILDKIT=1 docker build --target dev -t ghcr.io/edgelesssys/ego-dev - < Dockerfile
DOCKER_BUILDKIT=1 docker build --target deploy -t ghcr.io/edgelesssys/ego-deploy - < Dockerfile
```

The master branch can be built the same way by passing `--build-arg egotag=master --build-arg erttag=master`.

## Samples that answer the awkward questions

The samples directory is where this project tells you what it can actually do, and several of them exist to answer questions a sceptic would ask.

The reproducible_build sample builds the helloworld sample reproducibly, resulting in the same UniqueID. That is the direct answer to the question of whether an enclave measurement means anything, since a measurement that changes on every build cannot be compared against a known value by a remote verifier.

The cgo sample demonstrates the experimental cgo support, and the word experimental is the README's own. The wasmer and wasmtime samples show that WebAssembly can be run inside an EGo enclave, which is the route for porting a runtime rather than a program. The vault sample demonstrates how to port a Go application exemplified by Hashicorp Vault, which is a large, realistic Go codebase and therefore a real test of the compiler fork. The embedded_file sample shows how to embed files into an enclave.

The samples directory in the repository holds more than the README lists, including an aks entry, which lines up with the Azure attestation sample.

Taken together, the samples map onto the objections a security reviewer will raise. How do I know the same binary runs every time, how do I port a codebase that uses cgo, how do I verify a remote party, how do I keep state. The answers are in the tree rather than only in the documentation, which is the right place for them.

## EGo is one layer of a wider confidential stack

The README has a Beyond EGo section, and it is short enough to enumerate. MarbleRun is used to create distributed EGo applications and run them on Kubernetes. EStore is used to securely persist an application's data. And for anything that is not Go, Contrast is the option for running confidential containers on Kubernetes.

That last one is worth pausing on, because it defines EGo's boundary. EGo is a Go specific path into confidential computing: an adapted Go compiler, a signer, a runtime. If your workload is not Go, Contrast is the route the same vendor points you to, and the difference is that Contrast runs confidential containers rather than compiling a specific language into an enclave.

The Go module inside the repository is minimal, which is expected since most of the value is in the compiler and the CLI rather than in a library. It requires go-jose for JSON web tokens and cryptography, plus testify for tests, and it declares Go 1.21. The EGo API itself lives under the `attestation/` and `ecrypto/` directories in the tree, with the enclave loader under `enclave/` and the CLI under `ego/`.

The repository also holds a `pccs/` directory, a `marble/` directory for the MarbleRun integration, an `eclient/` directory, and the `_ertgo` directory holding the modified Go toolchain, which is a reminder that the compiler fork is a substantial part of what is being maintained.

## Licence, support and the hardware dependency

EGo is available under the MPL, and the README points at the LICENSE file. The Mozilla Public License is a file level copyleft licence, so modifications to the covered files require those files to stay open, while larger works that merely link against the library are not forced open. For enterprise support there is a separate commercial licence available from the vendor.

The maintenance record is active. The recent releases include v1.10.1 on 2026-10-19, v1.10.0 on 2026-09-09 and v1.9.1 on 2026-09-01, the repository is not archived, and the last push was on 2026-10-19.

The dependency on Intel SGX is the dominant constraint and it is worth being blunt about it. The enclaves are always-encrypted and verifiable only because the hardware provides the enclave and a trusted measurement of what runs inside it. That means the deployment target needs SGX, the host needs the SGX driver and platform software, and in production that usually means a cloud instance with the right processor generation and an attestation service. The DEB install path makes that explicit by adding the Intel SGX apt repository, so the platform component is part of the installation, not an optional extra.

This is the main reason EGo is not a drop-in replacement for a normal container. A container gives you isolation from other tenants of one host with a familiar operational model. An enclave gives you a stronger guarantee against the host itself, at the cost of a new deployment model, a new attestation flow, and hardware that not every machine has. If the threat model does not include the host operator, that trade is hard to justify.

Support channels are the usual ones: file an issue for a question, file a bug report for an error, and use the private GitHub vulnerability report or the security email for anything sensitive. The project also asks contributors to sign a Contributor License Agreement.

## Conclusion

Adopt EGo when you need to run Go code in an attested enclave on Intel SGX hardware and you want the build workflow to look like a normal Go build, with remote attestation and attested TLS available as libraries rather than as a platform rewrite. Do not adopt it for a workload that only needs encryption at rest, or for hardware without SGX, since the whole model depends on the enclave being attested by the platform. Before you start, install the snap or the DEB package plus gcc and libcrypto, verify the `ego-go build`, `ego sign` and `ego run` sequence on the helloworld sample, and decide early whether you need MarbleRun for orchestration, EStore for persistence, or the Contrast runtime for non-Go workloads.

## FAQ

### What is EGo and what does it let me build?

EGo is an open-source SDK for building confidential apps in Go that run in always-encrypted and verifiable enclaves on Intel SGX enabled hardware. It provides `ego-go`, an adapted Go compiler, and `ego`, a CLI for enclave tasks such as signing and creation.

### How do I install EGo?

The snap is the easiest route with `sudo snap install ego-dev --classic`, alongside gcc and libcrypto. Ubuntu 20.04, 22.04 and 24.04 users can install the DEB package, and there is also a source build and a reproducible Docker build.

### How do I build and run a confidential Go app with EGo?

Three commands: `ego-go build hello.go` to build an enclave-compatible executable, `ego sign hello` to sign it, and `ego run hello` to run it. The samples directory starts with helloworld as the minimal example.

### What is remote attestation in EGo and which sample shows it?

It is the mechanism by which a client verifies what is running inside the enclave. The remote_attestation sample shows the basic API and the attested_tls sample uses a higher level API to establish an attested TLS connection. An azure_attestation sample shows how to use Microsoft Azure Attestation.

### Is cgo supported by EGo?

Yes, but the README describes cgo support as experimental and provides a cgo sample. The vault sample shows how to port a Go application exemplified by Hashicorp Vault.

### How do I securely persist data from an EGo enclave?

Use EStore. The estore sample shows how to securely persist data using EStore, and the EGo API provides sealing so that data encrypted inside the enclave can only be decrypted by that same enclave.

## Sources

- [edgelesssys/ego on GitHub](https://github.com/edgelesssys/ego)
- [License: MPL-2.0](https://github.com/edgelesssys/ego/blob/master/LICENSE)
- [Project website](https://www.edgeless.systems/products/ego/)
- [README](https://github.com/edgelesssys/ego/blob/master/README.md)
- [Releases](https://github.com/edgelesssys/ego/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/edgelesssys-ego