FAQ

Is Obelisk just a deployment console?

No. Deployment is part of the product, but the system is broader than that.

Obelisk combines organization operations, runtime workflows, automation, billing, and platform governance in one control plane.

Who gets the most value from Obelisk?

Teams get the most value when they already feel the cost of fragmented operational tooling.

That usually includes:

• product and platform teams shipping runtime changes
• DevOps teams that need auditability and lifecycle controls
• operator-led companies that want billing, support, and customer workflows close to infrastructure work

For a stronger fit check, read Use Cases and Team Fit.

Why not just keep separate tools for infrastructure, billing, and support?

You can, until the handoffs between those systems become the real source of cost and risk.

Teams usually consolidate into Obelisk when the problem is no longer feature coverage. The problem is coordination, ownership, and lack of shared operational context.

For the longer argument, read Why Obelisk.

Do I need an organization before the product makes sense?

Yes, for most real workflows.

The organization is the tenant boundary for:

• settings
• runtime operations
• analytics
• billing
• API keys
• webhook configuration

Without an organization context, you are only seeing the edge of the product.

What is the difference between the organization workspace and the admin console?

The organization workspace is for tenant-local work. The admin console is for platform-wide governance across many organizations.

Operators should spend most of their time inside organization pages. Platform owners should use admin pages when they need cross-tenant visibility or intervention.

Can non-engineers use Obelisk effectively?

Yes, if their work depends on operational context.

Customer-facing operators, founders, finance owners, and support teams can use the workspace effectively because it includes:

• leads and activity
• notifications
• analytics
• billing
• support

Engineers are still critical for runtime-heavy workflows, but the product is not designed only for developers.

How does automation work without turning into a security mess?

Automation is exposed through controlled product surfaces such as:

• scoped API keys
• public deployment API routes
• outbound webhooks
• organization-aware permissions

The point is to enable automation while keeping auditability and access control intact.

Read more in Security and Governance.

When should we adopt Obelisk instead of stitching tools together?

Adopt it when at least a few of these are already true:

• you operate multiple customers or tenant workspaces
• runtime actions need durable history
• billing and operational usage need to be understood together
• support and escalation depend on product context
• platform admins need more than ad hoc scripts and dashboards

If your workflow is still a single developer and one simple deployment target, Obelisk is probably too much system.

Can we separate production and non-production workflows?

Yes, and you should.

The product's role model, credential model, and runtime workflow structure are much easier to operate when teams separate environments intentionally rather than reusing the same credentials and operational habits everywhere.

What should I read first if I only have a few minutes?

Read these pages in order:

1. Platform Overview: What Obelisk Operates
2. Quickstart: First 30 Minutes in Obelisk
3. Core Concepts

That sequence gives you product framing, hands-on orientation, and the underlying mental model.

Where do I go next after the FAQ?

• New to the product: Backend Getting Started: Sign-in, Organizations, Navigation
• Evaluating fit: Use Cases and Team Fit
• Learning by role: Reading Paths by Role
• Looking up terminology: Glossary