When DigitalOcean App Platform or Coolify fits your team
DigitalOcean App Platform fits teams that want DigitalOcean to run builds, runtime and patching for them. Coolify fits teams that want the same Git-push workflow on Linux servers they control. Most renewals, growing container bills or data residency rules lead to the same three questions: who operates the platform, where the data must physically live, and how much operating capacity the team has. A managed service answers the first question with the vendor, while a self-hosted platform answers it with your own staff.
Start with data residency. App Platform keeps builds, containers and managed databases in the regions DigitalOcean offers, so confirm with DigitalOcean whether those locations satisfy your rule before comparing prices. With Coolify, the application servers, databases and backup targets are the servers and object storage you choose. The Coolify installation documentation lists the minimum of 2 CPU cores, 2 GB RAM and 10 GB of free disk, and it supports only Linux distributions, so check that your approved hosts and images meet those requirements. Note that Coolify Cloud still places the Coolify instance on Coolify's infrastructure, so it does not answer a strict residency question on its own.
Then measure your operating capacity honestly. With Coolify, your team patches the host operating system, upgrades the coolify-proxy container, schedules and tests database backups, and responds to incidents on each server. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so plan those separately. The self-hosted edition is free to license, so the cost shifts to servers, storage and staff time. If nobody on your team owns on-call and restore testing, App Platform's managed operation is the safer fit. Ask Coolify and DigitalOcean for written scopes and quotes that include those operating tasks.
Which DigitalOcean App Platform alternative fits each team
This table maps common App Platform situations to the option that fits best and the condition that drives the choice. Read each row against your own staffing, infrastructure and data requirements, since the best fit depends on who will operate the platform after launch.
| Team situation | Better fit | Reason and condition |
|---|---|---|
| Small team with no platform staff | Stay on App Platform or a managed PaaS | Coolify and Dokku move patching, proxy, backups and incident response to your team. Choose self-hosting only if someone owns that work on a schedule. |
| Team already running Droplets or other Linux servers | Coolify | Coolify connects to servers over SSH and runs on Linux with at least 2 CPU cores, 2 GB RAM and 10 GB free disk, so existing servers can host several apps without a new bill per container. |
| Regulated workload that must stay on named infrastructure | Coolify or Dokku on named servers | Both run on servers you control. Confirm the data path, backup destinations and access controls with your auditor, since DeployOpen prepares evidence but does not issue attestations. |
| Many small services sharing servers | Coolify | Coolify deploys from Git, Dockerfile, Compose or image across multiple servers, which suits consolidating services. Confirm your server sizing and proxy choice before consolidating. |
| Team that needs a managed database with point-in-time recovery | App Platform managed databases, or evaluate Coolify carefully | Coolify schedules PostgreSQL dumps with retention rules but its docs describe pg_dump backups, not managed point-in-time recovery. Confirm PITR requirements with the vendor before choosing. |
| Team that relies on preview environments for every pull request | Coolify, with wildcard DNS in place | Coolify builds pull or merge requests from GitHub, GitLab, Gitea and Bitbucket and deletes them on close. Preview URLs need wildcard DNS, so confirm your DNS setup first. |
What Apache-2.0 and a free self-hosted edition change for you
The license decides what your team may do with Coolify's code, and the pricing page decides what you pay Coolify directly. Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. Coolify Cloud is a different product: it costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, and it runs Coolify's own instance on managed infrastructure while you bring the servers. Before you compare this with App Platform's container and bandwidth charges, confirm the current license text in the Coolify GitHub repository and the pricing terms on the Coolify pricing page, because both can change between your evaluation and your purchase.
In practical terms, Apache-2.0 generally permits your engineers to run the software internally, modify it for your own pipelines or templates, and fork it if the upstream project changes direction. It also permits redistribution, subject to the license conditions such as keeping the license notice and stating significant changes. Ask counsel or your procurement team to confirm how these conditions apply if you plan to ship a modified Coolify to customers, embed it in a product, or resell hosting built on it. Also check whether any third-party components or one-click service templates carry their own licenses, since those are separate from Coolify's core license.
A free license does not make the platform free to run. Your costs are the servers or Droplets, the staff hours to install, patch, back up and monitor Coolify and the proxy in front of it, and any support contract you choose to buy. Those costs recur monthly or yearly, while installation and the first migration are largely one-time. They rise with the number of servers, the size of databases you back up, and the number of people on call. When you build the quote for your own environment, ask the vendor or partner to separate software fees, infrastructure, implementation and ongoing support, so the comparison with App Platform reflects every component.
Capabilities of App Platform and Coolify side by side
This table compares how App Platform and Coolify handle builds, databases, previews, routing, scaling and licensing. Where App Platform details are not in our researched material, the table tells you what to confirm in DigitalOcean's current documentation. The main takeaway is that Coolify gives you more control over the stack and more operating responsibility, while App Platform keeps the platform operations with the vendor.
| Capability | DigitalOcean App Platform | Coolify (self-hosted) |
|---|---|---|
| Build methods | Buildpacks or Dockerfiles, confirm the current list of supported buildpacks in DigitalOcean's docs | Nixpacks, Railpack (beta), Static, Dockerfile, Docker Compose, plus Docker Image to skip the build |
| Hosting model | Managed containers on DigitalOcean infrastructure, you choose container sizes | Runs on servers you provide, connected over SSH, on Linux amd64 or arm64 |
| Databases and backups | Managed databases are sold separately, confirm backup and restore options in DigitalOcean's docs | PostgreSQL, MySQL, MariaDB, MongoDB, Redis and more; scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, not Redis |
| Preview deployments | Confirm pull request preview support in DigitalOcean's current documentation | Built for GitHub, GitLab, Gitea and Bitbucket requests; needs wildcard DNS and deletes previews when the request closes or merges |
| Reverse proxy and TLS | Handled by the managed platform, confirm custom domain and certificate behavior in DigitalOcean's docs | Traefik by default or Caddy, both issue HTTPS automatically; Custom (None) leaves routing and certificates to you |
| Scaling across servers | Scale by container size and count within the managed service, confirm current limits | Multi-server deployments are supported; you add and maintain each server yourself |
| License and ownership | Proprietary managed service, governed by DigitalOcean's terms | Apache-2.0 open source, self-hosted edition with no feature limits per Coolify's pricing page |
| Patching and incidents | Platform patching and incident response handled by DigitalOcean | Your team patches the host, Coolify and the proxy, and responds to incidents |
Where Coolify backups end and your recovery plan begins
Coolify schedules backups for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not for Redis, Dragonfly or KeyDB. Before you cut over, list every datastore your App Platform app uses and check each one against that split. A Redis or Valkey cache that holds session state or queue data needs its own backup approach, or a documented decision that losing it is acceptable. PostgreSQL backups use the pg_dump custom format, can be uploaded to S-3 compatible storage, and run on cron schedules with retention set by count, days or size. Confirm in your Coolify instance that the schedule, the destination bucket and the retention policy are all set for each database, because a backup that is configured but never tested tells you very little.
A rollback in Coolify can redeploy a retained application image, but it does not restore databases or persistent files. That means the recovery plan has to live outside the deployment tool. Decide where backup copies are stored, keep at least one copy outside the server that runs the database, and set retention so that a restore point from before a bad migration still exists when someone needs it. Schedule restore tests on a non-production host and record how long the restore took and which steps were manual. Persistent files used by the app, such as uploads, need the same treatment because Coolify does not capture them as part of a database backup. Ask your team who owns each step and who can approve a restore during an incident.
Compare this with the backup and recovery behavior of App Platform's managed databases before you decide. Read DigitalOcean's documentation for its managed database backups, including what is retained automatically, how point-in-time recovery or restore works for your database engine and plan, and whether restores create a new cluster. Then write down the gap for each datastore: what the managed service does for you, what you must build in Coolify, and who is paid or staffed to do it. The comparison should cover recovery time, not only whether a backup exists. Ask for a written restore procedure and a tested recovery time before you retire the App Platform databases.
Who holds the data, the patches and the access on each side
App Platform keeps the runtime, patching and much of the access model with DigitalOcean, while Coolify moves those duties onto your team. The cards below set out where data sits, who runs the control plane, and who patches and audits each layer, so you can match the choice to your residency and compliance obligations.
Where the application data lives
On App Platform, your databases and runtime sit in the DigitalOcean regions you select, and you rely on DigitalOcean's managed database service for backups. With Coolify, the data stays wherever you install the servers, whether that is a Droplet in a chosen region, a data center or an air-gapped network. Confirm which regions and providers hold application logs, build caches and database backup copies, including any S3-compatible storage you configure for Coolify backups.
Where the Coolify control plane runs
Coolify is the management layer that connects to your servers, so the decision is whether it runs on your infrastructure or on Coolify's managed service. Self-hosting the instance keeps the control plane inside your boundary, and the edition is licensed under Apache-2.0. Coolify Cloud keeps the instance on Coolify's infrastructure while your servers remain yours, which shifts operation of that instance to the vendor. Ask which option your data handling rules accept before any deployment begins.
SSH access to each server
Coolify connects to each server over SSH to prepare it for Docker workloads and deploy to it, so anyone who controls the instance can reach every connected host. Treat the SSH key that Coolify uses as a privileged credential: restrict who can add servers, rotate keys on a schedule and log changes. On App Platform, you never receive a shell on the runtime, so this exposure does not exist in the same form. Document which accounts and keys can reach production hosts.
Patching the operating system, Docker and proxy
On App Platform, DigitalOcean operates the underlying runtime, so your team does not patch the host, container engine or routing layer. With Coolify, your team patches the Linux distribution, the Docker engine and the coolify-proxy container on each server, and it upgrades the Coolify release itself. Traefik is the default proxy and Caddy is the alternative, both of which handle HTTPS automatically. Set a named owner and maintenance window for each layer, and confirm how the proxy is updated before relying on it.
Identity, roles and audit trails for the team
Review how team members sign in and what each role can change, since both platforms can alter production configuration. Confirm whether your identity provider can enforce single sign-on and multi-factor authentication for each platform, and how audit logs are retained and exported. Coolify's API uses tokens with defined permissions, so scope and rotate them as you would any deployment credential. Map each role to the change types it may make, including database restores and server additions.
Compliance evidence, not compliance outcomes
Either platform can support a compliance program, but neither product's configuration alone satisfies an assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors issue any reports or certifications. Ask each vendor which certifications it holds for the specific service you would use, and do not assume that a self-hosted Coolify instance inherits any provider's attestations. Plan the evidence trail for patching, access reviews and backup tests from the start.
What an App Platform alternative costs in components, not in license fees
Coolify is free to self-host, so the comparison with App Platform moves from a license line to a set of components: servers, storage, egress, DNS and staff time. The cards below separate what you pay DigitalOcean for, what you pay a provider or your own infrastructure for, and what work recurs after the first deployment.
App Platform bills by container and add-on
App Platform charges for each container size you run, plus bandwidth, managed databases, development databases and dedicated egress IPs when you enable them. Each of these is a separate line on the bill, so the total moves with how many components you deploy and how large each one is. Ask DigitalOcean for a written estimate using its current price pages and your own component list and traffic history, not a figure from this page.
Coolify software carries no license fee
The self-hosted Coolify edition is Apache-2.0 licensed and is free, so the license line that appears in a managed bill disappears. What remains is the infrastructure Coolify runs on: at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each Linux server, plus any hosted Coolify Cloud subscription if you choose that instead. Check the server sizing against the number of apps and databases you plan to run on each host.
Servers, storage, backups and egress
On Coolify, you pay a cloud or hosting provider directly for servers, block storage, backup storage (for example an S3-compatible bucket) and outbound transfer. Backup storage grows with retention settings, which Coolify sets by count, days or size. Egress is often the line that surprises teams, so measure it on your current App Platform bill before you move and compare it with the same traffic on your chosen provider.
One-time migration and setup work
The first-time costs are installation, migrating each app and database, designing the backup schedule and restore path, configuring DNS and wildcard records for preview deployments, and rehearsing the domain switch. These are one-time labor, whether done by your team or a fixed-scope partner. Ask for each item as a separate line in a written scope so you can see which parts repeat and which end at go-live.
Recurring patching, restore tests and upgrades
After go-live, the recurring work is applying operating system and Coolify updates, watching server health, verifying that scheduled database backups actually run, and testing restores. Coolify's backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any cache you depend on needs its own recovery plan. Staff time for this work recurs every month and is the main cost that scales with the number of hosts.
Staff time sets the real comparison
The fair comparison is App Platform fees against the hours your engineers spend on patching, on-call response, capacity planning and incident work for the servers you run. The hours depend on team size, existing Linux skills and how many environments you operate, so estimate them with your own team rather than with a generic figure. Ask any partner for a quote that names the staff effort assumed, the on-call scope and what happens when a server fails.
How much operating work Coolify adds, by where it runs
Running Coolify on a Droplet keeps the server inside your DigitalOcean account, but the Coolify instance, its reverse proxy and every application container are yours to operate. The installation docs set a floor of 2 CPU cores, 2 GB RAM and 10 GB of free disk, which a Droplet can meet, but the size you need depends on your own traffic and build load.
- Minimum hardware: 2 CPU cores, 2 GB RAM and 10 GB of free disk. Plan for more disk than the floor, because images, build caches and database volumes grow over time.
- Operating system: Pick a supported Linux distribution such as Ubuntu or Debian on amd64 or arm64, and confirm the Droplet image appears on the supported list.
- Installation: A single installation script prepares the host and starts Coolify. Your team runs it and must hold the administrative access it needs.
- Patching: Your team patches the Droplet operating system, Docker and Coolify. Work done by the cloud provider on its infrastructure does not extend to your guest OS.
- Incidents and backups: Your team detects, diagnoses and restores failures. Droplet backups and database backups are separate settings that you must configure and test.
Before you size the Droplet, check the current requirements and update steps in the Coolify installation docs.
Coolify runs on any supported Linux host, including bare metal, on-premises hardware, another cloud or a 64-bit Raspberry Pi. The choice of host usually depends on data location, network access and procurement, not on Coolify features. Whatever host you pick, the operating work stays with your team, and the hardware you own adds failure modes that a managed platform would otherwise absorb.
- Supported systems: Debian, Ubuntu, the Red Hat family, SUSE, Arch, Alpine and 64-bit Raspberry Pi OS, on amd64 or arm64.
- Connection model: Coolify connects over SSH and prepares each server to run Docker workloads, so SSH access and firewall rules must allow that path.
- Hardware planning: The same floor of 2 CPU cores, 2 GB RAM and 10 GB of free disk applies, but your application memory and disk needs decide the real size.
- Patching and hardware: Your team patches the OS, Docker and Coolify, and handles failures such as a failed disk or power loss. Confirm with your hosting provider who replaces hardware.
- Additional servers: Coolify can deploy to more than one server, and each server runs its own proxy container, so every server you add is one more host to patch and monitor.
Write down who owns hardware replacement, out-of-hours response and host access before you go live, and confirm your distribution and architecture against the installation docs.
Coolify Cloud runs the Coolify instance on Coolify's managed infrastructure while your applications run on servers you bring. The control plane work moves to the vendor, but the servers that host your workloads do not. Your team still owns the operating system, security and backups of each customer-owned server, so the reduction in work is smaller than with a fully managed PaaS.
- Pricing: Coolify's pricing page lists $5 per month for 2 connected servers and $3 per month for each additional server, with a 20% discount for annual billing.
- Host maintenance: You still patch and harden every customer-owned server and run its backups. The managed instance does not patch your application hosts.
- Platform responsibility: Coolify operates the managed instance. Ask for its availability commitments, incident response process and support hours in writing, because this page does not state any service levels.
- Staffing: Keep at least one person who can connect to servers over SSH, read Docker logs and restore databases from backup.
- Recovery: A rollback can redeploy a retained application image but does not restore databases or persistent files, so database backups remain your responsibility.
Before moving production workloads, request the managed instance's support terms and data handling in writing, and confirm how each connected server is backed up.
How a move from App Platform to Coolify runs in phases
The sequence moves each app, database and domain from App Platform to Coolify on servers you control, with a rollback period before anything is retired. Each phase ends with a check you can verify before the next one starts.
Inventory the app spec and dependencies
Start by exporting the App Platform app spec and listing every component: services, workers, jobs, static sites, databases, environment variables, routes and custom domains. Your platform or development team owns this inventory, and a security reviewer should check where secrets are stored today. The step is done when every component has a row in a written inventory that names its build source, its runtime settings and its data dependencies, and the team agrees the list is complete. The exact list depends on your app spec and data volume, so confirm the details against your own export.
Provision and harden the servers and Coolify
Provision the Linux servers that will host the workloads, then install Coolify on the instance that manages them. Coolify connects to each server over SSH, so the operations team should restrict SSH access, apply patching and firewall rules, and decide who holds administrator access to the Coolify dashboard and API. The step is done when the servers meet the minimum requirements in the installation documentation, Coolify can reach each one, and the team has documented who patches the hosts and who receives alerts. Confirm sizing with the vendor documentation and your own load profile.
Rebuild each component with a Dockerfile or build pack
Rebuild each inventoried component in Coolify using a Dockerfile, a Nixpacks or Railpack build pack, a static build, or a prebuilt image, depending on what the component needs. Developers move environment variables into Coolify and keep secrets out of the repository. The step is done when each component deploys from its source, starts with the same runtime configuration as on App Platform and passes its existing health checks in a staging environment. Note that Railpack is listed as beta in the current documentation, so teams should confirm its status before relying on it.
Move the database and test restores
Plan the database move with the data owner. Export the App Platform database, load it into the Coolify-managed database or your own managed service, and confirm the backup schedule covers the engine in use. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any cache with persistent data needs its own plan. The step is done when a restore from a Coolify backup into a separate environment completes, row counts or checksums match the source, and the team has written the recovery steps. Also note that Coolify's rollback redeploys application images but does not restore databases or persistent files.
Validate preview deployments against wildcard DNS
Configure wildcard DNS for the preview domain and connect the Git provider through Coolify's GitHub App, webhook, GitLab, Gitea or Bitbucket integration. Open a test pull or merge request and confirm Coolify builds it at the preview URL and removes it when the request closes or merges. The step is done when the preview deploys, the URL resolves and serves the staging build, and the team has confirmed that preview environments do not reach production data or secrets. Confirm access controls for preview environments with your security team.
Cut over domains in a planned window
Lower DNS record time-to-live values ahead of the change, agree a change window with the business owners, and point the production domains and TLS to the Coolify proxy. Coolify's proxy, Traefik by default or Caddy as an alternative, handles HTTPS for routed domains, and the team should verify certificate issuance before traffic moves. The step is done when production traffic reaches the Coolify-hosted apps, error rates and latency match the baseline, and the on-call team confirms the rollback path is ready if an issue appears.
Retire App Platform components after rollback
Keep the App Platform components running, and their databases intact, through an agreed rollback period after cutover. Once the period closes and the business signs off, remove the App Platform apps, revoke the credentials and API tokens they used, and cancel the related billing items. The step is done when the old components are removed, the credentials no longer work, the final backup is archived under your retention policy, and the updated inventory, runbooks and ownership records reflect the new Coolify estate.
What teams ask before moving off App Platform
How much effort does moving off App Platform to Coolify take?
The effort depends on how many apps, databases and domains you run, and on how much of your build and runtime configuration lives in App Platform's app spec. No researched figure for hours or cost is available for this move, so ask for a written scope that lists each app, each database and each domain before you compare quotes. Each app needs a build method chosen (Nixpacks, Dockerfile, Static, Docker Compose or a prebuilt image), environment variables re-entered and tested, and a cutover plan. Databases usually take the most care because they carry state. Ask for effort broken down by these components rather than a single number.
How long does a migration from App Platform to Coolify take?
No researched duration is available, so the timeline should come from your own inventory and a written scope. The main drivers are the number of apps, the size and count of databases, how many custom domains need DNS changes, and whether you need a parallel run before switching traffic. A small set of stateless apps can move quickly once a server is prepared. Database migrations and compliance evidence add time. Ask any provider for milestones tied to each app and each database, not a single end date.
Can an internal team migrate to Coolify without outside help?
Yes, if the team has Linux administration, Docker, DNS and TLS experience and time to own the work after cutover. Coolify installs with a single script on supported Linux distributions and needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk. The harder parts are operating the server, managing the proxy, planning backups and handling patches and incidents yourself. Be honest about who will carry that work for the next year. Outside help can be scoped for the migration only, or as an ongoing retainer.
What does the work need from our team during a migration?
Expect to provide access, decisions and time from several people. Platform or DevOps staff need server and DNS access. Application owners need to confirm build steps, runtime settings, environment variables and health checks. A database owner must approve the backup and restore approach and the cutover window. Security or compliance staff should review secrets handling, access control and logging. Naming these owners in the scope before work starts prevents most delays.
Does Coolify scale apps across multiple servers?
Coolify supports multi-server deployments, where you connect additional servers and choose where each application runs, but it does not replace a managed autoscaler. Scaling is handled by the servers you provision and the way you distribute workloads, so capacity planning, load balancing design and failover become your responsibility. Ask your team to confirm the multi-server behavior for the Coolify version you plan to run, including how the proxy and databases behave across nodes, against Coolify's multi-server documentation.
Is Coolify the right choice if an app needs managed scaling?
Usually not, if managed scaling is a hard requirement. App Platform and similar managed PaaS products handle container sizing and capacity for you, while Coolify runs on servers you size and operate. Coolify can suit workloads that tolerate planned capacity changes, or teams that want to control capacity directly. For apps with spiky traffic or strict availability targets, compare the operating cost of extra servers, monitoring and on-call coverage against the managed option before deciding. Keep the apps that need managed scaling on the managed platform if necessary.
What happens to backups after cutover?
Backups become your responsibility the day traffic moves. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, can upload to S3-compatible storage, and support retention by count, days or size. Redis, Dragonfly and KeyDB are not covered by scheduled backups, so plan those separately. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files. Test restores before cutover, and confirm offsite storage and retention with your compliance owner.
Who patches and responds to incidents after moving to Coolify?
Your team does, unless you buy support or a retainer from a provider. On App Platform, DigitalOcean operates the platform underneath your apps. On Coolify, you patch the host operating system, Docker, the Coolify release, the proxy and each database, and you respond when something fails. Coolify is licensed under Apache-2.0 and its self-hosted edition is free, so the recurring cost is staff time, server hosting and any support contract. Ask any provider for a written list of responsibilities, response expectations and the upgrade process for each component.
How DeployOpen helps you evaluate and move off App Platform
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For App Platform versus Coolify, we start with a written scope that tests whether Coolify fits your apps, databases and operating model before anything is moved.
How we scope
- Inventory every App Platform component, route, database and environment variable your apps depend on today.
- Define which servers, Droplets or other Linux hosts will run Coolify, and who owns them.
- Agree in writing which apps move first, which stay put, and what success looks like before work begins.
How we build
- Install Coolify on the agreed servers and configure the proxy, TLS and wildcard DNS for preview deployments.
- Rebuild each app from its Dockerfile or build pack and test it against the same behavior App Platform gave you.
- Set up database backups to S3-compatible storage with retention, and test a restore before cutover.
How we hand over
- Document server configuration, backup schedules, restore steps, domain changes and rollback procedures for your team.
- Walk your engineers through day-to-day deployments, preview environments and incident response on Coolify.
- Provide the written record your auditors or internal reviewers will ask for when you run the new platform.
How we support
- Engagements are fixed-scope, so the handover boundary is agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- Ask for a quote based on your written scope, which covers the servers, apps, databases and testing involved.
