Skip to main content

Development and Deployment

This FAQ answers common questions about technical requirements, submission processes, and version management for App Marketplace development.

Do I need to manage hosting or infrastructure?​

No. All marketplace apps run in Atlan's managed runtime environment, which includes:

  • Secure hosting
  • Identity and access control
  • Network isolation
  • Built-in orchestration, retries, and execution logging

You focus on app logic—everything else is handled by the framework.

What do I need to get started?​

You'll need:

  • Access to the Apps Framework SDK (GitHub)
  • CLI tools for building and deploying
  • A valid app.manifest.json to define scopes, UI locations, and triggers

Developer documentation, boilerplate templates, and sample apps are provided.

How are apps submitted to the marketplace?​

Apps are submitted via the slack with Atlan tenant team as of today.

Each submission must include:

  • The full app bundle (code, manifest, UI config)
  • Metadata access scopes documentation
  • App description, icon/logo, and usage instructions

All apps are reviewed for security, stability, and UX before being approved for publishing.

Can I track how my app is performing?​

Not yet. Observability is planned but not in production.

In future versions, developers have access to:

  • Execution logs (per app/version)
  • Runtime performance metrics
  • Error tracking and audit logs
  • Analytics for usage and installs (opt-in)

How are app versions managed?​

Apps support versioned deployments, where each version includes:

  • Immutable code and config
  • Registered UI locations
  • Scoped metadata access definitions

Customers can choose to:

  • Pin to a specific version
  • Enable autoupgrades
  • Roll back to previous versions

When to create custom typedefs​

Create custom typedefs when your data source contains asset types that don't match Atlan's standard types, or when you need custom attributes that aren't available in the default models. Custom typedefs are required when your asset relationships follow patterns that differ from Atlan's standard relationship models.

Use existing typedefs when your assets correspond to standard database concepts like tables, columns, or schemas, and you only need the default metadata and relationships. Standard typedefs provide better integration with Atlan's UI components and require less configuration.

Why use the typedef toolkit instead of raw JSON?​

The typedef toolkit abstracts the complexity into more manageable Pkl files (.pkl). This approach provides several advantages:

  • Single source of truth: One .pkl file defines all your connector's asset types
  • Automatic generation: The toolkit generates complete JSON schemas from your definitions
  • Inheritance handling: The toolkit automatically resolves and includes inherited properties
  • Relationship management: Bidirectional relationships are handled automatically

This approach ensures consistency and reduces the likelihood of errors in typedef definitions.

How are typedefs deployed and validated?​

After generation, you push the JSON files to the atlanhq/models repository. Once merged and deployed to an Atlan tenant, they become the validation schema for your connector's data.

Any data you send to Atlan's publish endpoint must strictly adhere to the attribute names and types defined in these generated models. If you try to publish an asset whose typedef doesn't exist, or if your data doesn't match the typedef structure, Atlan rejects it with a validation error.

Need help​

If you have questions about development and deployment that aren't covered in this FAQ, contact Atlan support by submitting a support request.