Skip to content
Nebula Logger

Package options

Nebula Logger ships as both an unlocked and a managed package, with the same core metadata. A third option is to bundle the metadata into your own project without a package boundary. The right choice depends on release cadence, namespace, and plugin support.

Comparison

AreaUnlockedManagedBundled
NamespaceNoneNebulaNone (you own it)
Release cadenceFaster patch cadenceSlower, stabilized cadence (~3 managed releases per year)Whatever you pull in
Source visibilityFull source in orgPackaged global API surface onlyFull source
Plugin frameworkAvailableNot currently availableAvailable
Feature coverageAll features, latest fixesSubset - trails the unlocked packageWhatever you copied
Distribution modelGitHub-first OSSAppExchange-friendlyYou ship it in your own package
Best forMost teamsISVs whose customers need namespace isolationTeams that need full control of what deploys

Start here unless you have a hard reason not to. The unlocked package:

  • Has faster patch cadence - new fixes and enhancements land quickly.
  • Exposes full source in the installed org.
  • Includes the plugin framework, so all the shipped plugins and any you write yourself work.
  • Is the reference implementation - if a feature exists in Nebula Logger, it exists here first.

Install steps: see Install the unlocked package.

Managed package

Choose the managed package only when you need namespace isolation:

  • You are shipping an AppExchange product whose customers need every custom object and class isolated behind a namespace.
  • Your org has policies that require namespaced installations for compliance.

Tradeoffs:

  • Slower release cadence than the unlocked package.
  • No plugin framework - the trigger and batch extension points are not exposed in the managed package.
  • API surface is only the classes and members marked global. Anything public in the source is not accessible from your code.

All Nebula Logger APIs referenced in this documentation are global, so they are available in both packages. Prefix them with Nebula. in the managed package (Nebula.Logger.info(...)).

Install steps: see Install the managed package.

Bundle without a package

If you need full control over what deploys and are willing to own the upgrade path, copy the metadata into your own project.

  • Full source, no namespace, no plugin package boundary.
  • You are responsible for pulling in updates - no automatic upgrade path.
  • Ideal for teams that want to ship a single deployment artifact.

Install steps: see Bundle without a dependency.

For ISVs and package developers

If you are building your own package and want to optionally use Nebula Logger when it’s installed in a customer’s org - without forcing customers to install it - use CallableLogger. Your package compiles and installs cleanly whether Nebula Logger is present or not. See Optional dependency via Callable.

Where next