Overview
How a Lunar Dedicated install works — a single-tenant install that Earthly provisions, operates, and upgrades end-to-end in a dedicated AWS account, reachable over the internet or over private network
Lunar Dedicated is a fully managed, single-tenant Lunar install. Earthly provisions, operates, and upgrades it end-to-end in an AWS account dedicated to you, and you choose whether to reach it over the internet or over private networking. It's for teams that want Lunar's guardrails without running the Hub themselves.
This page explains how it works, who it fits, and what Earthly needs from you to stand one up. Setup is the hands-on companion covering what your team actually does.
Lunar Dedicated is a managed offering, distinct from the self-hosted Lunar Hub. With Dedicated, Earthly runs the infrastructure; with the self-hosted Hub, you do. The CLI and CI tracer are installed and configured the same way in both.
How it works
One dedicated AWS account. The strongest isolation AWS offers: a hard billing and security boundary, with nothing else running inside it.
Earthly operates it by assuming an IAM role. Management is identity-based, so Earthly needs no VPN or peering to run your install.
You choose how the hub is reached. Over the internet on your own hostname, behind TLS and token authentication, or privately over PrivateLink with no public surface at all. Joining the two networks directly (peering / Transit Gateway) is coming soon. The webhook listener is public either way, since your Git platform delivers to it.
Your data stays in the install. Authoritative state (Postgres), run inputs and outputs (S3), and secrets all live in your dedicated account and region. Earthly stores none of your data centrally.
Earthly manages the whole lifecycle. Provisioning, version upgrades, patching, and monitoring, on a maintenance schedule you choose.
Requirements
Lunar Dedicated fits cleanly when the following are true:
Reachable CI
The Lunar CLI and CI tracer must run somewhere that can reach the hub. With internet access that's anywhere, including GitHub-hosted runners; with private access it means self-hosted runners in your network, or runners with VPN/PrivateLink access. On GitLab there is no tracer to place (tracing is coming soon), but the CLI still needs that reachability.
A network to connect from (private access only)
An AWS VPC that can reach a PrivateLink endpoint. Not needed if you reach the hub over the internet.
An outbound allowlist you can permit
The install needs egress for operational telemetry, container image pulls, and AWS APIs.
A single region
Each install lives in one AWS region.
Git platform credentials
On GitHub, a GitHub App you create and install on the org(s) and repositories Lunar should monitor. On GitLab, a group access token per top-level group. If your instance is self-managed and not reachable from the public internet, Lunar also needs a private path to it.
Coming soon. Joining your network to the install directly (VPC peering or Transit Gateway), connecting privately with no existing AWS footprint (site-to-site VPN), and multi-region installs are on the roadmap.
Need a fully air-gapped, no-egress install? Dedicated isn't air-gapped; it requires outbound egress to operate. For an air-gapped environment, the self-hosted Lunar Hub is a better fit. Book a demo to work with us.
How you connect
Two ways to reach your hub are available today, with a third on the way. Earthly helps you pick based on where your CI runs and what your security review requires.
Internet
PrivateLink
Joined network (peering / Transit Gateway)
Availability
Available now
Available now
Coming soon
What it is
The hub on your own hostname, behind TLS and token authentication
A private one-way "door" from your network to the hub
Your network and the install's network are routed together
Reaching the hub
From anywhere, including GitHub-hosted runners
Through one private endpoint you create
Over the joined network, at a private address
Address coordination
None
None (address ranges can overlap freely)
Address ranges must not overlap
Your setup effort
None
Create one endpoint
Accept the join and add routes (usually your networking team)
Best when
You want the simplest path, or your CI runs on hosted runners
Your security review rules out a public hub, and you want narrow exposure
You already run a Transit Gateway
Your install reaches outwards as well as inwards. The Hub calls your Git platform to read repositories, register webhooks, and post results; collectors, catalogers, and policies run inside your install and reach the systems they gather data from. For a dedicated customer any of those may be internal: a self-managed GitHub Enterprise Server or GitLab instance, registries, ticketing, internal APIs. That's why connectivity is two-way, and why onboarding asks where your CI runs and what your install needs to reach.
The two directions are set up independently, and you may need only one of them:
Reaching the hub: how your CI runners, CLI users, and browsers get to your install. Choose from the options above. Over the internet there's nothing for you to do; PrivateLink needs one step from you at go-live.
Lunar reaching your internal systems: needed if anything your install must reach sits off the public internet, such as a self-managed Git platform or an internal registry, ticketing system, or API. You publish each target as a PrivateLink endpoint service; see PrivateLink to Your Internal Systems. This one has a long lead time, so start it first.
What Earthly needs from you
These answers shape your install:
Region
Where the install (and your data) lives
Hub access
Internet or PrivateLink, and where your CI runs. Say so if you would rather join networks directly, so Earthly can tell you where that sits on the roadmap
Internal targets
Whether anything Lunar must reach sits off the public internet (a self-managed Git platform, or collector targets like internal registries, ticketing, or APIs), and if so, how many distinct hostnames. Drives PrivateLink to Your Internal Systems, the longest-lead-time item in onboarding
DNS
Use Earthly's subdomain (you.dedicated.earthly.dev), or delegate a subdomain of your own (e.g. lunar.yourco.com) for Earthly to manage
Git platform
Sizing
Rough org/repo count and CI volume, which maps to a t-shirt size (final sizing confirmed together)
Maintenance windows
A recurring weekly app window and a monthly infra window, in your timezone
Contacts
An operations contact (for maintenance notices) and a security contact (for incidents)
WAF (optional)
A web-application firewall on the public webhook listener; off by default, or on with a rule group you provide
Setup
Earthly handles initial provisioning and setup. This includes account creation, infrastructure provisioning, bringing up your hub, every upgrade (within your chosen window), version selection, monitoring, backup/restore, and clean offboarding.
However, we do need some help from your end.
What you do
Summarized here; Setup has the commands and is the page to work from.
Send your questionnaire answers. Earthly replies with your coordinates packet (tenant, region, dedicated account ID, deposit role ARN, deposit ExternalId, and your webhook URL) and starts building.
Start private access to your internal systems, if your Git platform or any collector target isn't on the public internet. Longest lead time in onboarding, so start it first.
Nominate your depositor account: the AWS account you'll deposit secrets from (there's a path for teams without one).
Set up your Git platform and send Earthly the identifiers: on GitHub the App ID, installation ID, and org; on GitLab the top-level group(s) and your instance hostname if you're self-managed.
Deposit your secrets: a ~30-minute terminal task once the packet and the credential exist. Secrets are written directly into your dedicated account's secret store through a write-only role, never through Earthly's systems.
Go live: Earthly verifies the install end-to-end and hands over your access token and Grafana login; you load workload secrets, finish DNS if you delegated a subdomain, and create your inbound endpoint if you chose PrivateLink.
None of this needs a meeting; most teams have all of it ready before their first call with Earthly.
Maintenance and upgrades
The Earthly team manages Lunar Hub updates for you; you choose when upgrades land. There are two recurring maintenance windows:
A weekly app window for routine Lunar version bumps (a rolling hub restart).
A monthly infra window for node patches, add-on updates, and the occasional infrastructure upgrade.
Every Dedicated install runs the hub redundantly, so routine upgrades roll through without taking the service down; expect at most a brief interruption as connections move. Planned windows are excluded from the uptime clock. Critical security patches and forced version deprecations can land out-of-window, with notice.
On GitLab, one recurring task stays with you. Group access tokens carry a fixed expiry, and there is no overlap period where old and new both work. Create the replacement in GitLab and deposit it ahead of the expiry date, using the same command as at setup, then revoke the old one. See expiry and rotation. If a token lapses, Lunar stops posting results and stops reacting to webhooks for that group. GitHub App credentials do not expire this way.
Security and data
How a Dedicated install handles isolation, data, secrets, and audit:
Exclusive, isolated account. Your install runs alone in a dedicated AWS account, with no other workloads.
Data residency. Authoritative state (Postgres), run inputs/outputs (S3), and secrets all live in your dedicated account and region. Earthly stores none of your data centrally.
Secrets are encrypted at rest, and Earthly never holds them. You deposit your Git platform credential (the GitHub App private key, or the GitLab group access token) into your install's own secret drop over a write-only role, and your workload secrets (API keys) go straight to your hub via the CLI. Neither passes through Earthly's central systems, and both live encrypted inside your install.
Full audit visibility. Every action Earthly's roles take is recorded in AWS CloudTrail.
Defined data lifecycle. Run inputs and outputs are retained 30 days. On exit, Earthly returns your data (a portable database dump plus your storage buckets) and provably deletes the install by destroying its encryption keys, with the deletion recorded in CloudTrail.
Operational telemetry is required. The install sends metrics and logs back to Earthly so it can monitor the install and meet the SLA. This covers operational data only (never your source code, data, or secrets), and Earthly details exactly what it includes in your security review. If you need telemetry fully off, the self-hosted Lunar Hub is a better fit; book a demo.
Custody is audited. Your secrets are encrypted with a key that lives inside your account and is readable only by the hub. Routine operation can't read your secrets, and any access that could is a deliberate, audited action. It is not a cryptographic guarantee that Earthly cannot read them. If you need hard zero-knowledge, the self-hosted Lunar Hub is the better fit; book a demo.
What's included
A single-tenant, fully managed Lunar install in a dedicated AWS account
Hub access over the internet, or privately via PrivateLink
A redundant hub, so planned upgrades roll through without downtime
A single region per install
Full lifecycle management: provisioning, upgrades, patching, monitoring, backup/restore, and clean offboarding
Next steps
Setup is where your team picks it up: the questionnaire, your depositor account, your Git platform credential, and the secret deposit.
If anything Lunar must reach sits off the public internet, such as a self-managed Git platform or a collector target, start PrivateLink to Your Internal Systems in parallel. It's the longest-lead-time item in onboarding.
Earthly is also glad to walk through the model live, answer your security team's questions, and map out what onboarding looks like for your environment.
Last updated