Apache Superset vs Redash: which fits an analyst team in production
Choose Apache Superset when your analysts will live in SQL every day and you expect the dashboard estate to grow into a governed, shared platform. Superset is Apache-2.0 with no paid edition, ships a SQL IDE and a no-code chart builder, and offers caching and a semantic layer. The price of that breadth is operational weight: a metadata database (PostgreSQL or MySQL, not the SQLite default), and for alerts, reports, async queries and dashboard thumbnails, a caching layer plus Celery worker and beat processes. Superset also requires a user-specified SECRET_KEY to start. On Kubernetes, the official Helm chart is now marked deprecated in current development docs, and the Superset Kubernetes Operator is still in alpha, so confirm its status with the project before you standardize on it. Choose Redash when the team wants a smaller footprint and a query editor with alerts, scheduled refreshes and a REST API, and can accept a slower release cadence. Redash is BSD-2-Clause and needs PostgreSQL, Redis and API and worker processes, with a recommended minimum of 4 GB of RAM. Its release history shows a gap from v10.1.0 in November 2021 to v25.1.0 in January 2025, so ask for a dated plan for security patches before committing.
The decision turns on four questions. First, maintenance tolerance: who applies upgrades, runs superset db upgrade and superset init after a backup, and reads UPDATING.md, and how quickly your team must absorb security releases. Second, scale and concurrency: whether you will need Celery workers and a caching tier from day one, and who monitors them. Third, identity needs: Superset maps OAuth2 or LDAP groups to roles through AUTH_ROLES_MAPPING, and Redash's setup guide points to Google OAuth for production, so test the sign-in path your directory actually uses. Fourth, migration appetite: moving saved queries, dashboards and alerts between the two is a rebuild, not a copy, so estimate that effort before choosing. Run a pilot on your real data sources, with a copy of the production schema, and time the upgrade path for each tool in your own environment.
Which scenario points to which platform
This table maps common team situations to the platform that usually fits better, with the reason and the conditions that could change the answer. Read each row as a starting point, then check the dependency column against your own hosting, staffing and security rules before deciding.
| Scenario | Better fit | Why and where it depends |
|---|---|---|
| Small analyst group on one host | Redash | Redash needs PostgreSQL, Redis and API and worker processes, with a recommended minimum of 4 GB RAM. Superset adds a metadata database, optional cache and Celery workers. Single-host fit depends on whether you will add those services. |
| Platform team serving many departments | Apache Superset | Superset has a semantic layer, role mapping from LDAP or OAuth groups and a documented Kubernetes operator path. Confirm your identity setup and whether the operator, currently in alpha, meets your rollout standards. |
| Alerts and scheduled reports at high volume | Apache Superset, if you run Celery workers | Alerts, reports and async queries rely on the caching layer and Celery worker and beat processes. Redash also offers alerts and scheduled refreshes. Test your expected job volume on both before choosing. |
| Strict maintenance and vulnerability-response requirements | Depends on your review process | Redash's release history paused from November 2021 to January 2025, then shipped v26.9.0 with 13 security advisories fixed. Superset ships releases on a regular cadence under Apache governance. Ask each project for its current support policy and advisory process. |
| Team already running Airflow | Apache Superset, if Airflow feeds a warehouse you query in SQL | Both are SQL-first and neither depends on Airflow. Airflow reaches end of life for Airflow 2 on April 22, 2026, so plan the upgrade path separately from the BI choice. |
| Team already running dbt | Either, depending on where metrics are defined | Redash and Superset both query the warehouse tables dbt builds. Superset's semantic layer can hold metric definitions in the tool, while Redash keeps logic in saved queries. Decide where your team wants metric ownership to sit. |
| Teams that need strict upgrade control and documented backups | Apache Superset | Superset's upgrade guidance asks you to back up the metadata database, run database upgrades, test in staging and read UPDATING.md. Redash has a simpler stack, but confirm its upgrade and backup steps against your own runbook. |
How Superset and Redash are built and what that means for operations
Both tools are SQL-first and both store their own application state, but they ask for different numbers of moving parts. The cards below set out each component, the database and memory requirements, and the checks that shape monitoring, sizing and upgrades for each platform.
Superset's four components
Superset runs as a Flask and React application, a metadata database, an optional caching layer, and optional Celery worker and beat processes. Only the first two are needed for a basic install. Alerts and reports, async queries and dashboard thumbnails depend on the cache and workers, so if you plan to use them, you must monitor and size those services as well. Confirm which features your team needs before you decide how many processes to run.
Superset metadata database choice
Superset is tested with PostgreSQL and MySQL as its metadata database. The SQLite default used by Quickstart and PyPI installs, and the Docker Compose PostgreSQL container, are not recommended for production. The configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported versions. Plan for a managed or highly available database with tested backups, because dashboards, users and permissions all live there.
Superset SECRET_KEY handling
Superset will not start until you set a user-specified SECRET_KEY, a requirement added in version 2.1.0. Losing or changing it without a plan breaks access to stored credentials and sessions. Superset supports rotation through PREVIOUS_SECRET_KEY. Treat the key as a managed secret, add rotation to your runbook, and confirm the procedure in staging before a production upgrade.
Redash's required services
A self-hosted Redash needs PostgreSQL, Redis, an API server and a background worker. That is four services before any monitoring or backup work begins. The worker handles scheduled refreshes and alerts, so a stopped worker means dashboards stop updating without an obvious front-end error. Add health checks for the worker and queue depth to your monitoring plan.
Redash setup options
Redash documents a setup script for modern Linux distributions, Docker images for Kubernetes, ECS or Docker Compose, and prebuilt AWS EC2 and Google Compute Engine images. The setup guide also recommends configuring a mail server, Google OAuth, HTTPS and environment variables for production. Choose the option that matches your existing platform team's skills, and confirm which settings your security review requires before you deploy.
Sizing and upgrade checks
Superset upgrades call for a metadata database backup, running superset db upgrade and superset init, a staging test, and a review of UPDATING.md for breaking changes. Redash has a long release gap, with v10.1.0 in November 2021 followed by v25.1.0 in January 2025, so its upgrade path may involve more change than the release count suggests. Ask each vendor for its supported upgrade path and test both in your own environment before you commit.
Capabilities side by side with supplied facts
This table compares the documented capabilities of Apache Superset and Redash on the points that usually decide a shortlist. Where the supplied facts do not settle a capability, the cell says what to confirm with the vendor or in a test environment. Read it as a starting checklist, then verify the rows that matter most to your analysts.
| Capability | Apache Superset | Redash |
|---|---|---|
| License | Apache-2.0, with no paid edition | BSD-2-Clause, open source |
| Data source coverage | Connects to SQL-speaking databases; confirm your specific driver | More than 35 SQL and NoSQL sources, including PostgreSQL, MySQL, BigQuery, Snowflake and Redshift |
| SQL editor | SQL Lab IDE for ad hoc queries | Query editor with schema browser and autocomplete |
| No-code chart builder | Yes, included in the platform | Drag-and-drop visualizations combined into dashboards |
| Alerts and scheduled refreshes | Alerts and reports require the caching layer and Celery workers | Alerts when data changes and scheduled refreshes listed in the README |
| REST API | Confirm endpoint coverage against your automation needs | REST API documented as covering all UI functionality |
| Caching and semantic layer | Caching layer and semantic layer both offered | Not covered in the supplied facts; confirm with the vendor |
| Identity options | OAuth2 (such as Google and Azure), LDAP, and AUTH_ROLES_MAPPING for group-to-role mapping | Setup guide recommends Google OAuth; confirm LDAP and group mapping |
| Kubernetes deployment path | Official Helm chart is deprecated; new deployments point to the Superset Kubernetes Operator, which is in alpha | Docker images for Kubernetes, ECS or Docker Compose |
| Latest release | 6.1.0 (May 13, 2026); 7.0.0 release candidates in October 2026 | v26.9.0 (September 24, 2026), after a gap from v10.1.0 in 2021 to v25.1.0 in 2025 |
What each license allows and what is paid for
Apache Superset is released under the Apache License 2.0 (SPDX identifier Apache-2.0), as shown on its PyPI package and repository. The Apache Software Foundation project has no paid edition, so the software you download is the full project and no feature tier needs to be purchased. The license covers use and modification of the software itself and says nothing about the services built around it.
- No paid edition: The project publishes no commercial tier, so the license fee is zero. Recurring spend falls on infrastructure, staff time and any outside support you contract separately.
- Modification rights: Apache-2.0 allows you to change the code for internal dashboards or your own distribution. This matters if you plan to customize charts or embed Superset in a product, and your legal team should confirm the attribution and notice obligations.
- Version cadence: Version 6.1.0 was released on May 13, 2026, and 7.0.0 release candidates appeared in October 2026. Budget upgrade work into your operating plan and follow the breaking-change notes in
UPDATING.md. - Operating costs: A self-hosted deployment needs a metadata database. Alerts, async queries and dashboard thumbnails also need a caching layer and Celery workers, and you run and pay for those yourself.
Ask the Apache Superset project and any third-party provider directly whether they offer hosted or support plans, and what those plans include in writing.
Redash is licensed under the BSD-2-Clause license, as shown in the getredash/redash repository, and describes itself as a tool to connect to any data source and visualize, dashboard and share data. BSD-2-Clause is a permissive license that allows use, modification and redistribution with conditions such as retaining the copyright notice. Like any license, it governs the code and does not promise maintenance, support or a release schedule.
- Permissive terms: BSD-2-Clause places light conditions on use and modification, so internal deployment carries no license fee.
- Release gap: After v10.1.0 in November 2021, the next release was v25.1.0 on January 8, 2025. The license does not address this, so weigh the gap in your own maintenance risk review.
- Recent security work: Version v26.9.0, released on September 24, 2026, fixed 13 security advisories. Your team needs to track releases and apply patches on its own schedule.
- Self-hosting costs: A self-hosted deployment needs PostgreSQL, Redis, and the API server and background worker processes. The setup guide recommends at least 4 GB of RAM.
Ask the Redash maintainers or any commercial provider whether they offer hosted, support or patching commitments, and get the scope and terms in writing before you rely on them.
Both licenses set the rules for using, modifying and redistributing the code. Neither license sets service levels, response times, hosting arrangements or security patch commitments, and neither should be read as a support contract. The paid or commercial pieces, if any, come from separate agreements with the vendor or a provider.
- Use and modification: Both projects permit internal use and modification. Before shipping a modified build to customers, confirm the redistribution conditions with counsel.
- Support is separate: Support, hosting and patching are contracted services. Ask who provides them, what response coverage applies and how long each version is supported.
- Hosted offers: Confirm with each vendor whether a hosted or managed service exists, what it costs and which data it processes.
- Embedding and resale: Embedding dashboards in a customer-facing product or reselling access depends on the license terms and your own contracts. Confirm both before you design the rollout.
- Written scope: If an implementation partner builds or hardens either tool, ask for a written scope that names each component and the license that governs it.
Before you decide, verify the license file in each repository and the current terms with each vendor, because these obligations change with new releases.
How the Redash release gap affects maintenance risk
The Redash release history matters more to maintenance risk than any single feature. After v10.1.0 in November 2021, the next release was v25.1.0 on January 8, 2025, so a team that deployed in 2022 had no upstream fixes to apply for more than three years. Since then, releases have resumed with v25.8.0, v26.3.0 and v26.9.0 on September 24, 2026, and that last release fixed 13 security advisories at once. Plan for security fixes to arrive in batches, not as a steady stream. Before you commit, ask the maintainers how advisories are published, how quickly fixes ship and whether a supported branch exists for older versions.
Superset follows a different pattern, with more visible version lines to track. According to PyPI, 6.0.0 was published on December 18, 2025 and 6.1.0 on May 13, 2026, and the GitHub releases page lists 7.0.0rc2 as a pre-release on October 16, 2026. Each upgrade carries a fixed routine: back up the metadata database, run superset db upgrade and superset init, test in staging, and check UPDATING.md for breaking changes. That routine recurs, so the staff time to test upgrades is the real cost. Confirm that your team can complete one staging cycle before each new line reaches your production environment.
Accept a Redash deployment only for an internal, lower-sensitivity analytics service with a named owner who watches advisories and can apply patches within days. Avoid it for internet-facing or compliance-scoped dashboards unless you have a funded plan for upstream monitoring or an outside retainer for patching. For Superset, accept 6.1.0 for production once your staging test passes, and treat 7.0.0 as a candidate to evaluate only after a stable release, since the October 2026 build is a pre-release. Avoid running any Superset line that you cannot upgrade within your change window.
What drives the running cost of each platform
Running either tool costs more than its license line, which is zero for both. The cost comes from the services you operate, the people who know them, the upgrade work you test and the support you buy. Use the cards below to turn each driver into questions for a written quote.
Metadata database, cache and workers
Superset needs a metadata database (PostgreSQL 10 to 17 or MySQL 5.7 and 8.x are the tested versions), and most installs add Redis and Celery for alerts, reports, async queries and thumbnails. Redash needs PostgreSQL, Redis, and API server and background worker processes. Both have infrastructure you pay to run, monitor and back up. Ask whether the quote includes sizing for the worker count you actually need.
Skills your team must already have
Superset operations draw on Python, Flask and, for production, Kubernetes, since the official Helm chart is now marked deprecated in favor of the Superset Kubernetes Operator, which is in alpha. Redash has a lighter operational surface, but its project history includes a gap from November 2021 to January 2025, so you need someone who can read its release notes and judge the risk. Staff time is usually the largest recurring cost, so price it explicitly.
Upgrade testing and pre-upgrade backups
Superset's upgrade guidance asks you to back up the metadata database, run superset db upgrade and superset init, test in staging first, and read UPDATING.md for breaking changes between versions. Each upgrade cycle therefore consumes test environments and engineer hours. Redash upgrades also need staging and backups, and its 26.9.0 release fixed 13 security advisories, so plan for security-driven upgrades on either tool.
Support from DeployOpen or the vendor
Neither tool has a paid edition from its maintainers that bundles support, and Superset has no paid edition at all. Support options are a fixed-scope implementation from DeployOpen, an ongoing retainer for upgrades and monitoring, or an internal on-call rota. Ask which of these the quote covers, who answers out-of-hours incidents, and whether upgrade testing is in scope or billed separately.
One-time versus recurring spend
One-time work includes architecture, installation, SSO and role mapping, data source connections and the first staging test. Recurring work includes patching, version upgrades, backup verification, monitoring and dashboard maintenance. Most of the recurring cost sits in the second group. Ask the quote to split these lines so you can compare the two tools on the same basis.
Costs that grow with users and data
Query load, cache size, worker concurrency and metadata database size rise with the number of dashboards, scheduled reports and the volume of data queried. Superset's Celery workers become more important as scheduled work grows, which raises worker count and monitoring effort. Redash's scheduled refreshes and alerts add the same pressure on its workers. Request a quote that states the user count, concurrency and data volume it was sized for.
Moving dashboards and queries from Redash to Superset, or the reverse
This sequence moves analyst work from one SQL-first tool to the other without losing track of what was connected, scheduled or permitted. It ends with a cutover you can verify against the source system, with a rollback path until the new environment matches the old one.
Inventory queries, dashboards, alerts and schedules
Name one owner for the inventory, usually the analytics lead, and list every saved query, dashboard, alert, refresh schedule and user group in the source tool. Mark which items are still used by checking recent run history and which belong to people who have left. The output is a spreadsheet with one row per object, a usage flag and a named business owner for each dashboard. The step is done when the owners have signed off that the list is complete and that retired items are marked for archiving rather than migration.
Map data source connections to the target
For each data source in the inventory, record the connection type, host, database name, credential owner and network path, then confirm the target tool supports the same database engine and version. Redash reaches more than 35 SQL and NoSQL sources, so check any NoSQL connection against Superset's SQL-based connection model before planning around it. Connection strings and passwords do not move as plain text, so plan to re-enter credentials through a secrets process. The output is a source-to-target map that a platform engineer has tested with a read-only account.
Export SQL text and rebuild charts and dashboards
Copy the SQL text of each saved query into the target SQL editor, which is the part that transfers directly, and then rebuild each visualization using the target's chart builder. Dashboard layout, filters, chart types and color choices are recreated by hand, so budget the rebuild by dashboard rather than by query. Confirm the export options each vendor documents for its current release, since the set of exportable objects differs between tools and between versions. The output is a rebuilt dashboard set where each chart points to the same query text as its source.
Recreate alerts and refresh schedules
Redash alerts fire when data changes and schedules refresh queries, while Superset handles alerts, reports and async queries through its Celery worker and beat processes. Recreate each alert with the same threshold, recipient list and evaluation frequency, then confirm the target has the caching layer, Redis and worker processes it needs to run them. Check that outgoing mail is configured on both sides before you enable anything. The output is a list of alerts with a test notification received by each recipient group.
Migrate identity, groups and roles
Map each source user group to a role in the target, starting from the access each dashboard actually needs. Superset supports OAuth2 providers and LDAP, and maps groups to roles through AUTH_ROLES_MAPPING, so confirm your identity provider sends the group claims you expect. Redash documents Google OAuth as a production sign-in option, so note any user who signs in differently today. The output is a role matrix signed off by the data owners, plus a test sign-in for one account per role.
Run parallel checks against the source
Run each migrated query and dashboard in both tools against the same data for a set period agreed by the owners, and compare row counts, totals and filter behavior. Differences usually come from time zones, null handling or default filters, not from the SQL itself. Record every mismatch and its cause in the migration log. The check is complete when each business-critical dashboard matches the source within the tolerance the data owner has approved in writing.
Cut over and keep the source read-only
Announce a cutover date, switch links and scheduled deliveries to the target, and set the source tool to read-only so no one edits a dashboard that is no longer watched. Keep the source running and its database backed up until the owners confirm that nothing was missed. For the target, take a metadata database backup before the first production change, following the upgrade and backup guidance in the Superset documentation. The output is a signed cutover record and a dated decommission plan for the source.
Where Superset and Redash implementations usually run long
Superset implementations usually run long in the services around the web application. The metadata database stores dashboards, charts and users, so it needs a supported production engine. The configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, and the Superset architecture documentation says the SQLite default and the Docker Compose PostgreSQL container are not recommended for production. Alerts and reports, async queries and dashboard thumbnails depend on Redis and Celery worker and beat processes, each needing wiring, monitoring and sizing. Superset also requires a user-specified SECRET_KEY to start. Decide who owns that value, where it is stored, and how it rotates with PREVIOUS_SECRET_KEY before the first deployment, since rotation is a planned step and not an afterthought.
Identity mapping is the next common source of rework. Superset is built on Flask-AppBuilder and maps LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING. Before build, list every directory group that should map to an analyst, editor or admin role, and confirm with your identity team how group claims arrive from your OAuth provider. Kubernetes is the other open decision. The 6.1.0 documentation describes the official Helm chart, but the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Confirm the operator's current maturity against your production support expectations, and settle whether your platform team will own the chart or operator, custom images and upgrade testing in staging.
Redash effort sits mostly in surrounding configuration. The setup guide recommends a mail server, Google OAuth, HTTPS and environment variables for production, and the self-hosted stack needs PostgreSQL, Redis, API server and background worker processes, with a recommended minimum of 4 GB of RAM. Most engagements are fixed-scope, so the written scope should name each of these items, the environments involved, and who supplies the mail relay, certificates and identity provider settings. Change requests usually appear when a late decision adds a new identity provider, a data source that needs new network access, or a switch in deployment method after build has started. Put the change process and its acceptance steps into the agreed scope before work begins.
Questions buyers ask before choosing or hiring help
Is Apache Superset or Redash free to run?
Both licenses allow free use of the code, so the software itself has no license fee. Apache Superset is Apache-2.0 licensed and the project has no paid edition. Redash is BSD-2-Clause licensed. What you pay for is the infrastructure and the people. A self-hosted Superset needs a metadata database, and production guidance points to PostgreSQL or MySQL, plus Redis and Celery workers if you use alerts, reports, async queries or dashboard thumbnails. A self-hosted Redash needs PostgreSQL, Redis, and API server and worker processes, with a documented minimum of 4 GB of RAM. Ask any vendor or partner to price the hosting, backups, monitoring and upgrade time as separate lines so you can compare the two honestly.
What does running either tool need from our internal team?
Plan for ongoing operator time, not only setup. For Superset, the work includes running the metadata database and its backups, operating caching and worker processes, managing SECRET_KEY rotation, and upgrading with superset db upgrade and superset init after a metadata database backup, testing in staging and checking UPDATING.md for breaking changes. For Redash, the work is smaller in component count but still includes PostgreSQL, Redis, mail, HTTPS, OAuth and environment configuration. Identify who owns on-call for the data platform, who approves upgrades, and which analysts will build dashboards versus who will only read them.
Can a small team run Superset or Redash alone?
A small team with one or two engineers who already operate PostgreSQL and containers can run Redash with a limited service footprint, provided someone owns upgrades and security patches. Superset is reasonable for a small team only if it accepts the extra moving parts: Celery workers, beat processes and Redis are needed for the features that matter most to scheduled reporting. If your team has no one who can troubleshoot a worker queue or a database migration, budget for outside help or a retainer, which DeployOpen offers for ongoing support and upgrades. Test this by running a staged upgrade with your own staff before committing.
Does the Helm chart deprecation affect new Superset installs?
Yes, for new Kubernetes deployments. The Superset 6.1.0 documentation describes installs with the official Helm chart, but the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Existing Helm-based installs can keep running, but plan a migration path before you standardize on them. If you are starting now, evaluate the operator first and confirm its maturity with the project, since the operator is documented as alpha. Compare it against Docker Compose or a PyPI install if Kubernetes is not a firm requirement.
Is Redash's gap in releases a blocker?
It depends on how much you rely on the project's pace. After v10.1.0 in November 2021, the next release was v25.1.0 on January 8, 2025, followed by v25.8.0, v26.3.0 and v26.9.0 on September 24, 2026, which fixed 13 security advisories. The gap is a maintenance risk: a long pause means fewer fixes for the period, and the recent catch-up shows active security work. Before adopting it, review the changelog for your data sources, confirm who will apply future security releases, and decide whether an unmaintained period would be acceptable for the data you expose. Superset has a steadier release record, with 6.0.0 on December 18, 2025 and 6.1.0 on May 13, 2026, but both tools still need a patch process.
How is a migration from Redash to Superset scoped?
Scope a migration by inventory, not by tool. Count the queries, dashboards, alerts, scheduled refreshes, data source connections and users with their access rules. Superset uses its own SQL Lab and chart builder, so saved queries and visualizations generally need to be rebuilt or re-created rather than copied directly, and alerts and scheduled reports need the worker setup in place first. The effort rises with the number of dashboards that depend on Redash-specific visualizations and with the amount of access control you need to reproduce. Ask any implementer for a written inventory step, a staging plan and a cutover checklist before you agree on scope.
What does a fixed-scope engagement with DeployOpen cover?
A fixed-scope engagement covers the scope, deliverables and timeline that you and DeployOpen agree in writing before work starts. For a Superset or Redash project, that can include planning the architecture, implementing the metadata database, cache and worker services inside your own infrastructure, integrating identity, hardening, configuring backups, documenting the runbook and preparing upgrade procedures. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for a list of what is in and out of scope, who performs each task, and how acceptance is verified.
How DeployOpen helps teams choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For Apache Superset vs Redash, the work starts with a written scope that fits the team's data sources, sign-in requirements and operating capacity, so the choice rests on the client's own environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which SQL data sources, sign-in methods and user groups the dashboards must reach.
- We confirm whether the team needs Celery workers, a caching layer and alerting, or a single web process.
How we build
- We deploy the chosen tool in your cloud account, data center or air-gapped network, not on a vendor-hosted service.
- We configure the metadata database, secret handling, HTTPS, mail and identity integration to your standards.
- We test dashboards, scheduled refreshes and alert paths in staging before any production cutover.
How we hand over
- We document the architecture, configuration keys, backup steps and upgrade procedure for your own operators.
- We prepare a migration plan for moving saved queries, dashboards and users if the team switches tools.
- We walk your platform and security staff through runbooks and record what each component requires to run.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade work follows your staging tests and the vendor's breaking-change notes before production changes.
- We can run security testing on the deployed dashboards, APIs and surrounding infrastructure on request.
