SatBase

SatBase, on a host you own.

The public catalog and your internal parts on one instance inside your network. Your tools read it. The internet cannot reach it.

YOUR NETWORKSIGNED SNAPSHOTpulled by your instanceegress only · optionalONE LINUX HOSTyour data center or your clouddatabasefilesbackupsweb appAPIproxybrowserSSOAPI keys
Fig. 1. Exploded view of one instance. Every layer runs on infrastructure you operate. The only line that crosses your boundary is the snapshot your instance pulls, and you can leave it off.
01 Access
browser with SSO · API keys
02 Application
web app · API · your proxy, TLS
03 Data
relational DB · S3-style files
04 Host
one host covers most teams
0 inbound ports opened on your firewall
1 egress rule, to satbase.com, and only if you want updates
0 internal records in any request that leaves

Built for teams that cannot use a public tool

01

Primes and integrators

One approved parts list across programs, beside the public catalog your engineers already search.

02

Agencies and labs

Isolated networks, procurement rules, and data that is not allowed to leave the building.

03

Programs under ITAR and EAR

Controlled technical data inside an environment and access model you already govern.

The public catalog, plus everything you cannot publish

The same product your engineers use on satbase.com, with your parts, approvals and files beside the public records. One search, one set of filters, one comparison, across both.

One search across both

Internal parts and public records on the same template, with your program approvals in the row.

Every part carries what your team knows

Approvals, qualification files and notes on the record, not in a spreadsheet three folders away.

Same template, internal or public

Filter and compare on the same parameters across both.

Your identity provider, your roles

Sign-in through SSO. Roles you assign, with an audit log of changes.

Your systems read it through the API

The same API the public platform exposes, with keys your administrators issue and revoke. Updates arrive as signed snapshots you can inspect.

Public records come in. Nothing goes out.

SatBase publishes the public catalog as a signed snapshot. On the schedule you set, your instance opens one connection to satbase.com, fetches the snapshot, checks the signature and applies it. Or it arrives on a disk. Either way, the request carries nothing about your users, your parts or your searches.

INTERNETsatbase.comsigned snapshotAnyone elsethe internet1 · request2 · snapshot backverified, appliedno routeYOUR FIREWALLEGRESS443YOUR NETWORKYour SatBase instancecatalog.acme.internal · your TLSIdentity provider · SSOSAML · OIDC · yoursDatabase · files · backupsservices you run · nothing leavesWEB APP · SINGLE SIGN-ONYour engineerssearch · compare · approveAPI · KEYS YOU ISSUEPLMpart master · readRequirements toolapproved parts · readProcurementsupplier records · read
Fig. 2. The data boundary. One egress rule for the pull, no inbound route for anyone. Inside, your engineers use the web app with single sign-on and your systems read the API with keys you issue.

What a snapshot contains

  • New and updated public component records
  • Supplier profiles and contact details
  • Taxonomy changes and specification templates
  • Images and datasheets for public records

How it crosses

  • Your instance opens one HTTPS connection to satbase.com, on the schedule you set
  • One egress rule on your firewall; no inbound port, nothing listens
  • The signature is checked on your instance before anything is applied
  • Or no connection at all: downloaded elsewhere, carried in on media, verified on arrival

What never leaves

  • Your parts, suppliers and files
  • Program approvals, evaluations and notes
  • User accounts and who searched for what
  • Usage and activity data

Same application. Three places to put it.

Nothing about the application changes between them. What changes is where it lives, and how the catalog snapshot gets to it.

satbase.comsnapshotsFIREWALL443Your instanceon your hostsegress onlyyour data center · your rack

Your data center

Where
Hosts you operate, inside your network
Network
Reachable on your network only; one egress rule for the pull, or none
Updates
Snapshots pulled on your schedule
Releases
Pulled the same way, or delivered as a package
Fits
Primes and integrators with infrastructure already in place
satbase.comsnapshotsYOUR AWS · AZURE · GCP ACCOUNTprivate subnet · your security groupsNAT egressYour instanceno public endpointyour cloud tenancy · private access only

Your cloud tenancy

Where
An AWS, Azure or Google Cloud account you control
Network
Private subnet, no public endpoint, one NAT egress for the pull
Updates
Snapshots pulled on your schedule
Releases
Pulled the same way
Fits
Teams without a data center that still need isolation
satbase.compackageWorkstationdownloadsigned packagecarried on mediaNO CONNECTIONInstanceverifies itair-gapped network

Air-gapped

Where
Hosts with no external connection at all
Network
None
Updates
Downloaded on a connected workstation, carried in on media, verified on the instance
Releases
Carried in the same way
Fits
Agencies, labs and classified programs

What it runs on

The pieces, and what each one asks of your environment. Versions and sizing are in the security overview.

Host
One Linux host is enough for most teams; scale out when you need to
Database
A relational database you host, on the same machine or your existing service
File storage
S3-compatible object storage for images, datasheets and files
Identity
Your identity provider over SAML or OIDC
TLS
Your reverse proxy, your certificates
Email
Outbound SMTP for notifications, optional
Outbound
One HTTPS connection to satbase.com, or none

You run

  • Hosts, database and backups
  • Network, certificates and identity
  • Day-to-day operations
  • The decision to pull each snapshot

We supply

  • The application and its releases
  • Signed catalog snapshots
  • Deployment support and a security overview
  • Import help for your parts lists
PDF

Security overview for your reviewers

Architecture, data flows, the update mechanism and operational responsibilities. Ask for it in the form below.

Request the document

The answers your reviewers will ask for

Six facts about the deployment, each one a design decision rather than a setting.

Single sign-on via your identity provider

SAML or OIDC. No local passwords required.

Roles you assign, with an audit log

Who changed what, and when, on every internal record.

Your certificates, your proxy

TLS terminates on infrastructure you control.

No telemetry

The instance reports nothing back. Snapshot requests carry no account, usage or search data.

Signed releases and snapshots

Verified on the instance before anything is applied.

Export at any time

Your data lives in your database and storage. Stop the licence and the instance keeps running.

From security review to a running instance

Connected deployments are the quickest. Air-gapped installs add the time your own transfer process needs.

  1. 01

    Scope and security review

    We walk through your environment, data sensitivity, identity setup and network constraints with your security and IT teams.

  2. 02

    Install in your environment

    SatBase is installed on hosts you operate. You hold the keys, the certificates and the database.

  3. 03

    Load your catalog

    Import parts lists, supplier records, datasheets and program notes. Turn on public catalog updates, or leave them off.

  4. 04

    Operate and update

    Your team runs it day to day. We supply releases and support on the cadence you set.

Common questions

Something else? Ask us directly.

Can it run fully air-gapped?
Yes. With no external connection, catalog updates and software releases are delivered as a signed package that your team applies on its own schedule.
What data leaves our environment?
Nothing you add. If you enable public catalog updates, the connection is one-way into your instance. Your parts, suppliers, files, notes, users and search activity stay inside.
Does it help with ITAR and EAR data?
It keeps controlled technical data inside an environment and access model your organization already governs. Whether a deployment meets your obligations is your compliance team’s determination; we scope the deployment with them at the table.
How do we get our existing parts data in?
Spreadsheet and CSV imports for parts lists, approved parts and supplier records, and the API for everything else. We help map your fields during onboarding.
Who keeps it running?
Your team operates the hosts and the database. SatBase provides releases, deployment support and maintenance options that fit your environment, including offline releases for isolated deployments.
How is it licensed?
Per instance on an annual term, with releases, catalog snapshots and support included. Pricing depends on environment, number of users, integrations and support level.
What happens if we stop?
Your instance keeps running. Without a licence you stop receiving snapshots and releases. Your data is in your own database and storage, and you can export it at any time.

Talk to us about on-prem

Tell us about your program and environment. We will come back with the deployment shape that fits and what it takes to get there.

What happens next

  • A reply by email from the SatBase team
  • A scoping call with your security and IT contacts
  • A written deployment plan and a quote

Prefer a document first? Say so in your message and we will send the security overview for your reviewers.

Request a scoping call

The SatBase team replies by email.