GitNotebooks Enterprise Security

This page offers an overview of GitNotebooks security-related features. Note that while there are many ways to configure GitNotebooks we'll only discuss the most secure configuration here.

Everything on this page applies to both self-hosted and managed Enterprise instances. A managed instance is just a self-hosted instance that we run for you (outside your VPN), configured as follows:

  • GitNotebooks web application servers and image storage run in AWS.
  • All secrets are stored in AWS Secret Manager, with audit trails enabled.
  • All data is stored in RDS with TLS communication required, data encypted at rest, not internet-facing


This is the recommended architecture for a self-hosted deployment, which is also used for the managed Enterprise instances. The diagram summarizes the various components and how they communicate:

Architecture diagram

If using GitHub Enterprise Server, all network traffic remains within your corporate VPN.

Note: While we replicate the deployment across two Availability Zones for Managed Enterprise accounts, this is not strictly necessary for Self-Hosted.

Network Security

This is the recommended network security configuration for a self-hosted deployment, which is also used for the managed Enterprise instances. The table summarizes the inbound/outbound rules for each components as well as their internet configuration. In the case of Self-Hosted with GitHub Server, the application load balancer should not be internet facing, and only accept requests within the corporate VPN.

ServiceInboundOutboundInternet-FacingInternet Access
Application Load BalancerTCP:80 (redirect to 443)
TCP:443 GitHub and Corporate VPN
TCP:3000 Web application security groupYesN/A
Web application instanceTCP:3000 ALB security groupTCP:443 GitHub
TCP:443 Bugsnag
RDS PostgresTCP:5432 Web application security groupNoneNoNo

Data Encryption

Data Encyption At Rest

There are two pieces of sensitive data stored by the application. Both are AES encypted at rest:

  • GitHub Auth Tokens
  • Comment Body

In the case of self-hosted, the encyption key is generated by you. It's recommended that this key be stored in a secrets manager and mounted into the container image by reference.

Data Encyption in Transit

For Managed Enterprise accounts, the following components use TLS encyption:

  • Application Load Balancer
  • Database
  • GitHub Enterprise

It is recommended that network traffic be encrypted similarly for self-hosted deployments.


GitNotebooks relies entirely on GitHub Enterprise (GHE) for authentication. If you've configured your GHE instance to use SSO via SAML then GitNotebooks will use that too. There are no separate local user accounts to maintain within Gitnotebooks.

When a user signs in, GitNotebooks obtains and stores an OAuth token that lets it operatore on the user's behalf within the scopes that were granted. GitNotebooks needs the following scopes:

  • Repo (read and write)
  • Pull requests (write)
  • Metadata (read and write)


Authorizations in GitNotebooks are inferred from the permissions granted to users in GHE, i.e. repository read/write/admin and organization owner. There are no separate roles or authorizations maintained within GitNotebooks.

Data Flow

The following diagrams illustrate the two primary workflows of GitNotebooks

Login Data Flow Review Data Flow

Frequently Asked Questions

Does the self-hosted application send any network requests to GitNotebooks?

No, self-hosted installations do not make any network requests except to GitHub. If hosting GitHub Enterprise Server, all network traffic remains within your VPN. It is recommended that you restrict network requests from the application server to your GitHub Enterprise Cloud environment if using GitHub Enterprise Cloud.

Does GitNotebooks have access to any Self Hosted data?

No, all data is stored within your own cloud environment. GitNotebooks does not have access to any of your data.