FAQ

essesseff is a self-service DevOps platform that provides RBACed GitOps-, ClickOps- and API-driven Application Lifecycle Management.

It enables teams to build, deploy, and promote applications through a trunk-based GitOps workflow with full visibility and audit trails.

essesseff integrates with GitHub and Argo CD, giving you complete control over your code, configuration, and infrastructure with zero vendor lock-in.

1. Source repository
2. Helm config repositories (environment-specific):
   • config-dev
   • config-qa
   • config-staging
   • config-prod
3. Argo CD repositories:
   • argocd-dev
   • argocd-qa
   • argocd-staging
   • argocd-prod

It depends. If your account is intended to be a "Read-Only" essesseff user account only, then no you do not need a GitHub account. Otherwise, yes, essesseff requires a GitHub account.

You'll need to link your GitHub account to your essesseff account (from your essesseff personal account settings page), and you'll need a GitHub organization to create apps.

essesseff uses GitHub for source code management, GitHub Actions for builds, and GitHub Container Registry (GHCR) for storing container images.

Each essesseff app license includes:

• Configuration and use of 9 GitHub repositories for orchestrating code build, code/config deployment, promotion, and lifecycle management (source + 4 Helm config repos (environment-specific) + 4 argocd-env repos)
• Unlimited team members and centrally managed RBAC across all GitHub organizations and repositories
• Full RBACed GitOps-, ClickOps- and API-driven DevOps Application Lifecycle Management
• Self-service onboarding and operations
• Complete visibility and audit trail of builds, deployments, and promotions
• Integration with GitHub and Argo CD
• Zero vendor lock-in - you own your code, config, and infrastructure

essesseff uses a simple per-app subscription model.

Currently, we offer the Single App Bundle (x1app) with monthly ($100/month) or yearly ($1,100/year) billing options.

Each license covers configuration and use of 9 GitHub repositories for one complete application.

You can have unlimited team members and deployments per app license.

essesseff stores a maximum of 430 days worth of build, deployment, and promotion events for active accounts.

Also, when an essesseff app is removed from essesseff, its license can be re-used on another essesseff app.

Yes, you can cancel your subscription at any time from your account settings.

Since you own your code, configuration, and infrastructure (GitHub repositories, GitHub Actions, GHCR images, Argo CD, and Kubernetes), there's no vendor lock-in.

When you cancel, you retain full access to and control over all of your resources. However, all essesseff app event data (build, deployment, and promotion events) stored in essesseff will be deleted.

Yes, essesseff requires you to have your own Kubernetes cluster(s) (designated as DEV, QA, STAGING and/or PROD) and Argo CD installation(s). essesseff app templates (many of which are free to use) provide extensive documentation and automation on how to install and configure Argo CD from essesseff app repositories.

For the fastest path to getting started, consider using the essesseff onboarding utility, which automates both essesseff app creation and Argo CD setup for multiple environments in under five minutes. For more details, see: https://www.essesseff.com/docs/deployment/essesseff-onboarding-utility

essesseff orchestrates deployments, promotions, and GitOps configuration updates via Argo CD by updating image tag versions in the values.yaml files of the Helm config repositories (environment-specific) (config-dev, config-qa, config-staging, config-prod). You maintain full control over your infrastructure, including your Kubernetes cluster(s) and Argo CD installation(s). This ensures zero vendor lock-in and gives you complete ownership of your deployment platform.

Personal accounts are for individual users. Team accounts allow multiple users to collaborate on apps, organizations, and deployments. Team accounts support role-based access control (RBAC) with the following roles:

• Account Admin (owner)
• DevOps Engineer
• Developer
• QA Engineer
• Release Engineer
• Read-Only User

1. Sign up for an essesseff account and link your GitHub account
2. Create or join a team account
3. Add a subscription to your team account
4. Create a GitHub organization (or use an existing one)
5. Create your first essesseff app
   • essesseff will automatically create and configure the 9 GitHub repositories (source + 4 Helm config repos (environment-specific) + 4 argocd-env repos) for orchestrating your GitOps workflow
   • essesseff app template(s) provide "golden path" out-of-the-box functioning app image builds, and detailed information and automation on how to configure Argo CD in your Kubernetes cluster(s), with an especially streamlined experience when used in combination with the essesseff onboarding utility. For more details, see: https://www.essesseff.com/docs/deployment/essesseff-onboarding-utility

Nothing changes - you keep everything. Since essesseff uses your own GitHub repositories, GitHub Actions, GitHub Container Registry, Argo CD, and Kubernetes infrastructure, all your code, configurations, images, and deployments remain fully under your control. essesseff simply stops orchestrating GitOps configuration updates (updating Helm config repositories (environment-specific) with image tags) and stops storing build/deployment/promotion event history, and you lose access to the essesseff UX (for centrally managing team members and roles, efficiently managing lifecycle of essesseff apps as logical constructs, for code promotion/re-deploy/rollback, etc.), but you can continue using all your code/config/infra resources independently if you choose.

When you create a new essesseff app, essesseff creates 9 new GitHub repositories for you. If you have existing code, you can push it to the source repository that essesseff creates. essesseff manages the image tag/version in the values.yaml files of the Helm config repositories (environment-specific) (config-dev, config-qa, config-staging, config-prod) to maintain the GitOps workflow structure, but otherwise you are free to use and extend your Helm charts, overrides, and other configurations.

Yes, essesseff's opinionated trunk-based GitOps architecture supports multiple environments (DEV, QA, STAGING and PROD) through the Helm config repositories (environment-specific):

• config-dev
• config-qa
• config-staging
• config-prod

You can find your invoices in your team account's billing settings. Navigate to your team account, then go to the Billing section to view and download your invoices.

We accept all major credit cards, Paypal, etc. through our payment processor, Stripe. Payment is processed securely and automatically for recurring subscriptions.

Currently, essesseff offers the Single App Bundle (x1app) subscription plan. If you need more apps, you can purchase additional app licenses in bundled quantities of your choosing. Subscribed to licenses are pooled together, and app licenses are applied in a first-in-last-out (FILO) manner. Plan changes can be made from your team account's billing settings.

We're happy to discuss custom pricing for non-profits and educational institutions. Please get in touch through the contact page.

1. Your code lives in your GitHub repositories
2. Your builds run in your GitHub Actions workflows
3. Your container images are stored in your GitHub Container Registry
4. Your deployments are performed by your Argo CD installation on your Kubernetes cluster
5. Your applications run on your Kubernetes cluster
6. essesseff orchestrates deployments, promotions, and GitOps configuration updates via Argo CD by updating image tag versions in the values.yaml files of the Helm config repositories (environment-specific) and Argo CD repositories that coordinate the aforementioned systems
7. You can stop using essesseff at any time and continue with your existing infrastructure, code, and configurations

1. Account Admin (owner)
   • Full account control
   • Billing management
   • User and role management
   • As well as all permissions of all other roles
2. DevOps Engineer
   • DevOps operations
   • Organization and repository management
   • User management
   • As well as all permissions of all other roles except Account Admin
3. Developer
   • Write access to development repositories
   • Create pull requests
   • Full GitOps-driven CI/CD to development environment
   • Declare release candidates
4. QA Engineer
   • Write access to QA repositories
   • Acceptance (promotion) or rejection of declared release candidates (acceptance triggers deployment to QA)
   • After deployment to QA, declaration of release candidates as stable or rejected
   • Testing and quality assurance
5. Release Engineer
   • Release management and deployment coordination of releases declared stable by QA to staging and production deployment targets
6. Read-Only User (member)
   • View-only access to account resources

1. Captures the push event and creates an image record
2. Monitors the GitHub Actions workflow run for build status
3. Tracks when the container image is published to GitHub Container Registry
4. Upon detecting a successful image publish event from GitHub, essesseff automatically updates the image tag version in the values.yaml file of the config-dev Helm config repository, which triggers Argo CD to perform the deployment to your Kubernetes cluster
5. Subsequently:
   • Developers may then propose an image deployed to DEV be promoted to QA by declaring it a release candidate
   • QA Engineers may accept or reject release candidates
   • If accepted by QA, essesseff orchestrates the promotion via Argo CD by updating the image tag version in the values.yaml file of the config-qa Helm config repository, which triggers Argo CD to perform the deployment to the QA environment
   • QA may still reject a release candidate or declare it stable
   • If declared stable by QA, a Release Engineer may then promote the stable release image to staging and/or production. essesseff orchestrates the promotion via Argo CD by updating the image tag version in the values.yaml file of the corresponding config-staging or config-prod Helm config repository, which triggers Argo CD to perform the deployment to the corresponding Kubernetes environment(s)
6. essesseff provides full audit trail of who built, deployed, and promoted what, when, and where across the entire image lifecycle

Provided you use a similarly configured "app-of-apps" implementation of Argo CD on your Kubernetes cluster(s), yes, essesseff should work with your existing Argo CD installation. essesseff orchestrates deployments, promotions, and GitOps configuration updates via Argo CD by updating the image tag/version in the values.yaml files of the Helm config repositories (environment-specific) (config-dev, config-qa, config-staging, config-prod) that Argo CD monitors. When you promote applications in essesseff, it updates these repositories with the promoted image tags, which triggers Argo CD to perform deployments to your Kubernetes cluster(s).

However, it is much more likely that you will have a working Argo CD configuration if you use the automation included in essesseff-provided app templates.

1. List all available templates (global and account-specific)
2. Create essesseff apps with all 9 repositories via the API
3. Set up Argo CD applications for multiple environments (dev, qa, staging, prod) in one command
4. Automatically handle rate limiting and error handling

1. Template management - List and retrieve global and account-specific templates
2. App management - Create, list, update, and retrieve essesseff apps
3. Deployment tracking - List deployments and filter by environment and status
4. Image management - List container images and retrieve image details by tag
5. Retention policies - Manage image retention policies for apps
6. Notifications - Retrieve notifications-secret.yaml for Argo CD setup
7. Organization management - List and retrieve GitHub organization details

We're happy to discuss private or dedicated SaaS deployment options for organizations with specific security, compliance, or infrastructure requirements. Please get in touch through the contact page.

Activity of the essesseff-github-automation GitHub App can be monitored in your GitHub organization's audit logs. You can review these logs at any time in your GitHub organization settings to see exactly what actions essesseff has taken in your organization. The GitHub API is also available for implementing programmatic monitoring of GitHub organization audit logs.

You cannot without effectively breaking integration with essesseff. However, you can extend image registry(ies) beyond GHCR, as discussed in this blog post: https://www.essesseff.com/blog/container-registry-comparison

1. Simpler RBAC: Each repo is one permission boundary. essesseff roles map directly to GitHub repo access (e.g. who can push to config-prod). There are no path-based approval rules, CODEOWNERS, or branch policies to maintain—just straightforward repo-level permissions.
2. Distinct change history and audit trail: Each environment has its own git history. "What changed in prod?" means opening the prod config repo and reading the log. No filtering a monorepo by path or digging through unrelated commits. Blame, compliance, and rollbacks stay scoped to the environment.
3. Simplicity via separation: We chose "more repos, each with a single concern and simple rules" over "one repo with complex conventions to get the same isolation." For a golden path and role-based control, that trade keeps the model easy to explain and operate.