Why Apache Fineract high availability starts with instance roles
High availability for Apache Fineract starts with a decision most teams skip: which instance does what. Consider a bank or lender running Fineract for customer accounts and nightly processing (illustrative). If the team places several identical Fineract instances behind a load balancer and assumes uptime follows, the first write, the first schema change or the first nightly run will expose the gap. For this platform, high availability means assigning distinct roles to instances, not just adding copies.
The difficulty comes from how Fineract handles work. Writes take one path, so a design that lets every instance accept state-changing requests has to be checked against how the platform records transactions and balances. Liquibase database migrations run only on write instances, so a rolling deployment that treats every node as interchangeable can leave the schema in a state the rest of the fleet does not expect. The Close of Business Day Spring Batch job adds a third constraint. The Fineract README notes that it can run for several hours on deployments with millions of accounts, so its timing, its node and its failure handling shape the whole operating model.
The Fineract README also warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Organizations may pay a vendor for deployment and maintenance for exactly this reason. The practical consequence is that the role layout, the database topology and the batch design are the buyer's responsibility to specify, test and document. Nothing in the upstream project settles these choices for a specific institution's load, recovery targets or regulatory obligations.
Before any build work, the team should answer several questions in writing. Which instance will be the single write instance, and what happens to writes if it fails? Which instance runs the batch job, and does the batch workload have a fixed window? Which read instances serve reporting and customer self-service, and are they allowed to lag behind the write path? Who runs schema migrations, and in what order do nodes change version? Each answer constrains the next, so the role map should be settled before the database replication, load balancing or batch partitioning design begins.
Which Fineract roles and PostgreSQL parts make up the setup
A highly available Fineract setup is a set of separate roles rather than one scaled-out server. Each role has a fixed job, and the roles share a PostgreSQL estate, a tenants database and, for batch scaling, a message broker. The cards below name each part, what it must never do, and what to confirm in the documentation for the release you choose.
Write instance
The write instance handles state-changing API calls and is the only role that should run Liquibase database migrations, according to the Fineract documentation. It must never be pointed at a read replica, because writes need the primary. Before go-live, confirm in the documentation for your chosen release (the current stable line is 1.15.0) how the write instance is selected through its environment variables and how migrations are sequenced during upgrades.
Read instances
Read instances serve query-heavy API traffic and are configured to connect to database read replicas, which the documentation recommends for high load alongside multiple read instances. They must never perform writes or run migrations. Confirm which read-only endpoints and reporting paths the release supports on read instances, and test any custom report that assumes it sees the latest committed data, since replicas can lag the primary.
Batch instance
The batch instance runs scheduled jobs such as the Close of Business Day job, which can take several hours on deployments with millions of accounts. It must not serve interactive API traffic, so nightly load never competes with branch staff. Confirm in the documentation how the batch role is enabled, how job schedules are set, and whether worker nodes are needed for remote partitioning in your release.
PostgreSQL primary and replicas
PostgreSQL is the database the Fineract README recommends, while MariaDB and MySQL are deprecated under FSIP-9. The primary takes all writes, and replicas take read traffic. Replica lag, failover promotion and connection limits per instance are the main operational risks. Ask your database team to define the replication method, failover runbook and recovery targets, and confirm which Fineract settings point each role at the correct host.
Tenants database and tenant headers
Fineract is multi-tenant. Tenant connections are configured from a tenants database, and each API request carries the Fineract-Platform-TenantId header. This database is a single point of dependency for every tenant, so it must be backed up and included in failover design. Never let a client omit or guess the tenant header at the load balancer, and confirm how the release handles tenant lookup when the tenants database is unavailable.
Load balancer and message broker
The load balancer sits in front of the API and routes requests only to healthy read or write instances, while the message broker (ActiveMQ or Kafka) carries work between batch partitions and, if enabled, external business events. Routing must never send write traffic to read instances, and brokers must not be exposed publicly. Confirm the health check endpoints, sticky session needs and broker configuration in the documentation for your release. Fineract is headless, so the front end is a separate component that calls these APIs.
Which high availability topology fits your uptime and batch window
This table compares the main Fineract topologies by when each fits, how exposed it is to failover time and replica lag, and how much operational effort it asks for. Read each row against your uptime target and the length of your Close of Business window, since batch placement drives both. The main takeaway is that read scaling and batch isolation are separate decisions, and the documented high-load pattern separates all three roles.
| Option | When it fits | Failover and replica lag exposure | Operational effort and testing |
|---|---|---|---|
| Single write instance with warm standby database | Moderate transaction volume, where a short outage during database failover is acceptable and batch runs on the write node. | Writes stop until the standby is promoted and the application reconnects. Recovery time depends on your failover process. | Standby promotion, reconnection and restore steps need regular rehearsal with your DBA team. |
| Single write instance with multiple read instances on replicas | Read-heavy channels and reporting grow faster than write load, and you want to offload queries from the write path. | Read instances can lag behind recent postings, so balances and statements may show older data. Write failover still follows the database process. | Requires routing rules, lag monitoring and tests that confirm which endpoints tolerate stale reads. |
| Separate batch instance alongside write and read instances | Close of Business runs long enough to compete with daytime transactions, or account counts are large. | A batch failure is isolated from customer writes, but batch still depends on the primary database being healthy. | One more instance to size, deploy, patch and monitor. Batch restart and rerun procedures must be documented and tested. |
| Batch on the write node | Smaller deployments with a batch run that finishes comfortably inside the nightly window. | A long or failing batch job shares resources with live writes. Failover of the write node also interrupts batch. | Fewer components to run, but batch timing and resource contention need monitoring and a tested rerun path. |
| Documented high-load pattern | High load, where the Fineract documentation recommends separate write, batch and read roles. | Each role fails and recovers on its own path, and read lag stays confined to read endpoints. | Highest component count. Staffing covers three instance types and replica monitoring, and Liquibase runs only on write instances. |
| Database failover tooling | An open choice. The project recommends PostgreSQL, and the tool that promotes a standby is your decision. | Failover time and data loss exposure depend on the tool and its settings. Confirm measured values in your environment. | Select, test and document the tooling with your DBA team, and ask partners to show test evidence before go-live. |
How to build the Fineract high availability setup in order
This sequence builds Fineract high availability in the order the platform depends on: database first, then schema, then the write, batch and read roles, and finally traffic routing and messaging. Each step closes with a check, so faults surface before the next layer is added.
Provision PostgreSQL primary and replicas
Your database team provisions one PostgreSQL primary and the replicas that the read instances will use, with streaming replication between them. Before any application starts, check replication state on the primary and confirm each replica is streaming with a replay lag reading your team has agreed is acceptable. Confirm the replicas reject writes. The step is done when every replica reports a healthy streaming state and the lag stays stable under test load.
Create tenants database and verify connections
Create the tenants database that Fineract reads to find each tenant's connection details, then register each tenant with its own schema and credentials. Confirm the setup with a test API call that carries the Fineract-Platform-TenantId header for each tenant, and check that the response contains only that tenant's data. Confirm that an unknown tenant identifier is rejected. The step is done when every registered tenant responds correctly and no tenant can read another's records.
Start write instance and run Liquibase first
Start one write instance pointed at the primary and let it run the Liquibase database migrations before any other instance starts. Liquibase runs only on write instances, so this is the only place schema changes are applied. On Kubernetes, the migrations can run as a separate job using the liquibase-only Spring profile. The step is done when the migration log shows every changeset applied and the write instance's health response reports ready.
Start batch instance with its own settings
Start the batch instance with its own environment settings so it runs scheduled work such as Close of Business without serving API traffic. Point it at the primary and the same tenants database, and keep it out of the load balancer pool. Confirm the instance type in its startup log and check that it reports a healthy batch role. The step is done when a test scheduled run starts and completes against a non-production tenant.
Add read instances on replicas
Add read instances configured with the read instance type and pointed at the replicas, never the primary. Scale read capacity by adding more instances with the same configuration. Send a GET request to each read instance to confirm it succeeds, then send a write request and confirm it is refused. Check replica lag again while read load is applied. The step is done when write attempts against read instances fail and the primary's write activity does not change.
Place load balancer and route by role
Place the load balancer in front of the instances and route by role. Send write methods to the write instance, read methods to the read pool, and keep the batch instance off any public route. Use each role's health response as the backend check so a failed instance leaves its pool. Send a GET and a POST through the balancer and review which backend logged each request. The step is done when each request type lands on the intended role and a stopped read instance drops out of rotation without client errors.
Configure HTTPS and broker partitioning
Enable HTTPS only using the SSL settings in environment variables, including FINERACT_SERVER_SSL_ENABLED, and replace default credentials before any user traffic. If Close of Business will use remote partitioning, set up ActiveMQ or Kafka and the worker nodes that connect through it. External event publishing is disabled by default, so enable it only where a consumer exists. Confirm HTTPS responses on each role. The step is done when plain HTTP is refused, the broker shows the workers connected, and a test partitioned job completes.
How high availability differs on VMs, Kubernetes and air-gapped networks
On virtual machines, the main design task is mapping Fineract's instance roles to hosts and making sure each host starts with the right role. Fineract documentation describes read, write and batch instance types set through environment variables, and recommends one write instance, one batch instance and several read instances on database read replicas for high load. Each role is a separate application process, so it is common to give each role its own VM or its own service unit on a shared VM.
Points to design and check:
- Role mapping: Record which host runs the write, batch and read roles, and set the instance type on each host through its environment variables.
- Service manager: Run each instance under a service manager that restarts it on failure and starts it in a known order, so the write instance is available when migrations run.
- Liquibase placement: Liquibase migrations run only on write instances, so restarts of other roles should not trigger schema work.
- Load balancing: Place a load balancer in front of the read instances and health-check each one before it receives traffic.
- Replica routing: Confirm that read instances point to PostgreSQL read replicas and that the write and batch roles point to the primary.
Confirm with your platform team which service manager, restart policy and health checks are standard in your environment, and how host patching is scheduled so that no two roles that depend on each other restart together.
On Kubernetes, the central risk is that schema changes and pod restarts happen at the same time. Fineract documentation states that Liquibase migrations run only on write instances and that, on Kubernetes, they can run separately with the liquibase-only Spring profile. Running migrations in their own workload keeps schema changes from racing with rolling updates of the application pods.
Points to design and check:
- Separate migration workload: Deploy a one-off job or a single-replica workload that runs with the liquibase-only profile and completes before new application pods start.
- Rollout order: Update the migration workload first, confirm it has finished successfully, then roll the write, batch and read deployments.
- Independent scaling: Scale read deployments on their own, since they do not run migrations and can be added or removed without touching the write role.
- Batch workload: Keep the Close of Business batch role on a deployment that is not scaled by traffic, so a scale event does not start a second batch run.
- Probes and disruption budgets: Set readiness checks on each role and a pod disruption budget so cluster maintenance cannot remove every read pod at once.
Confirm with your platform team the exact Spring profile name in the release you deploy, how your Helm charts or manifests expose it, and which ingress and database endpoints each role uses.
In an air-gapped or restricted network, high availability depends on moving every artifact in, verifying it, and keeping replication traffic inside the boundary. The cluster or VMs cannot pull images, drivers or dependencies from public registries at runtime, so the whole supply chain must be staged in advance. Fineract's README recommends PostgreSQL and notes that the official Docker image ships only the PostgreSQL JDBC driver, which is a useful starting point for your bill of materials.
Points to design and check:
- Image transfer: Mirror the Fineract images and any front-end images into an internal registry, and record their digests so the deployed version is traceable.
- Driver handling: Confirm the PostgreSQL JDBC driver version bundled in the image you approved, and stage any additional driver you need in the same controlled process.
- Verification: Check checksums or signatures on every artifact before it enters the network, and compare them again after transfer.
- Replication path: Keep primary-to-replica PostgreSQL traffic and any ActiveMQ or Kafka traffic on internal addresses, with firewall rules that match the instance roles.
- Upgrade staging: Repeat the transfer and verification for each quarterly release you adopt, since the upgrade path depends on the same artifacts.
Confirm with your platform team which internal registry, artifact repository and transfer approval process apply, and whether time synchronization, backups and monitoring can reach their endpoints without external services.
What drives high availability effort and cost on Fineract
This table lists the factors that change the design, build, testing and running cost of a highly available Fineract deployment, and what keeps each one manageable. Read each row as a lever: the driver on the left raises effort when it grows, and the right-hand column names the decision that holds it down. The main takeaway is that recovery targets, tenant count and batch sizing are settled early, because they set most of the one-time build and the recurring capacity bill.
| Driver | How it raises effort or cost | What keeps it down |
|---|---|---|
| Account and transaction volume | Higher volume lengthens the Close of Business Day batch, which the README notes can run for several hours on deployments with millions of accounts, and it requires larger read replicas and more batch capacity. Partitioning and load testing grow with it. | Measure current and projected account and transaction counts before design. Size the batch job and remote partitioning workers against a tested Close of Business window, and confirm replica sizing with load tests rather than assumptions. |
| Number of tenants | Each tenant adds connection configuration, data separation checks, per-tenant backup and restore steps, and tests. Shared clusters couple tenants' batch windows and failure domains. | Agree the tenant list early and limit the number of tenants per cluster. Confirm the operating limits for multi-tenant deployments with the project documentation and your own load tests. |
| Integrations that read from Fineract | Each reporting, payment or CRM consumer reading from Fineract adds read load, failover routing decisions and tests for stale data. External events published to ActiveMQ or Kafka add broker high availability as well. | Inventory every consumer and classify it as read, write or event-driven. Route reporting reads to read replicas and agree which consumers must survive a primary failover. |
| Required failover recovery target | A tighter recovery time or recovery point target typically needs synchronous or near-synchronous replication, automated failover tooling, and more frequent drills. Each step up adds design work and recurring infrastructure cost. | Have the business set recovery time and recovery point targets in writing before design begins. Map each target to a specific architecture choice so trade-offs are visible to the decision makers. |
| Number of environments | Every environment that must mirror production (test, staging, disaster recovery, performance) needs its own replication topology, batch configuration and monitoring. Keeping them in step is an ongoing task. | Define which environments must mirror production and which can run at reduced size. Automate environment builds from the same configuration to reduce drift. |
| Regulatory evidence needed | Assessors expect documented design, tested failover results, backup restore records and change history. Producing this evidence adds documentation, test runs and retained logs. DeployOpen prepares evidence, but independent auditors assess it. | Ask the auditor or regulator which evidence they expect before testing starts, and build the evidence capture into the test scripts. Confirm retention requirements for logs and test reports with your compliance team. |
| Depth of failover testing | Testing a single database failover is cheaper than testing instance loss during Close of Business, a network partition between write and batch nodes, or a full region loss. Deeper tests need longer maintenance windows and more people. | Agree a test matrix in the scope. Start with the failure scenarios that map directly to the recovery targets, and repeat them after each Fineract upgrade or infrastructure change. |
| Recurring running costs | Replica instances, batch workers, message brokers, monitoring, backups and on-call coverage recur every month. Drills and upgrades add periodic effort on top. | Ask any quote to separate one-time design, build and testing from recurring infrastructure, monitoring and support, with the assumptions for each stated. Confirm which items your own cloud or data center already covers. |
How to keep Close of Business reliable when nodes fail
The Close of Business Day job is the Spring Batch process that closes out each business day in Apache Fineract, and high availability for this job is mainly about making a long run survive a node loss without corrupting books or starting a second run. The Fineract README notes that this job can run for several hours on deployments with millions of accounts, so a failure late in the run is the case to plan for. Your team should decide, before go-live, which node runs the batch, how a failed run is detected, and who is allowed to restart it.
Restart behavior depends on the job repository. Spring Batch records step and job execution state in its own tables in the database, so a restarted job can resume from the last completed step rather than from the beginning, provided the failed execution is marked as failed and not left running. Confirm with the Fineract release you run how the batch metadata tables are created and migrated, and test a deliberate kill of the batch process during a rehearsal run. If the restart rewinds work that already posted journal entries, you need a documented rule for reconciling those entries before the job is run again.
The larger risk is a second batch instance starting the same business day. Fineract's documentation describes read, write and batch instance types set by environment variables, and a batch instance should be the only node with the batch role enabled for its tenant. Duplicate starts can happen when an orchestrator retries a job it believes has failed, or when a health check restarts a node that is still working. Put a single scheduler in charge of launching the job, use database-level locking or job parameters that make a duplicate launch fail fast, and alert on any run that starts while another is marked as running.
Batch load on the primary database is the other side of this problem. Fineract's documentation recommends separate read instances on database read replicas for high load, which keeps reporting and API reads away from the write path, but the batch job still writes heavily and must run against the primary. Ask your database team to size connection pools for the batch instance separately from the API nodes, and to confirm how replication lag affects any read that the batch depends on. Read replicas should not be used as a source for batch decisions unless lag is measured and bounded.
The cut-off time is a business decision, and high availability only makes it achievable. Ask operations and finance to state the latest time the end-of-day position must be available, how long a restart may take, and what happens to customer-facing channels if the cut-off is missed. Work backward from those answers to set alerting thresholds, a named on-call owner for the batch, and a manual fallback. Record the agreed cut-off, the restart procedure and the escalation path in the runbook, and rehearse them with the staff who will actually perform them. The step design and partition sizing that make the job faster belong to the Close of Business batch topic, not this one.
Securing the database, load balancer and replication paths
A highly available Fineract topology multiplies the places where credentials, certificates and network paths can be exposed. Each card below covers one of those paths, from database roles and replication accounts to broker access and TLS on the load balancer and between instances.
Separate database roles for each instance type
Write, batch and read instances should each connect with their own database role, so a read replica cannot write and a batch worker cannot reach more than it needs. Confirm with your DBA which role each instance type uses, which schemas and tenant databases each role can reach, and that read instances are granted read-only privileges on the replica. Review the role list whenever a new instance type or tenant is added.
Replace the default development login
The README's default development login of mifos with password must be replaced before any environment carries real data, including staging copies made from production. Check every instance, the tenants database and any admin or tooling account for the default. Store the new credentials in a secrets manager and confirm the default no longer authenticates on the load balancer path or any internal endpoint.
Replication user credentials and network scope
PostgreSQL streaming replication uses a dedicated replication account that can read the full write-ahead stream. Restrict that account to the replica addresses, use a separate credential from application roles, and rotate it on a documented schedule. Confirm that read replicas are reachable only from the Fineract read tier and the replication network, not from the wider corporate or tenant segments.
Broker credentials for batch and events
Remote partitioning of the Close of Business job uses ActiveMQ or Kafka, and external business events can also flow through the same brokers when enabled. Each producer and consumer should authenticate with its own broker identity and topic or queue permissions. Confirm that worker nodes can publish and consume only the destinations they need, and that the event feature is still disabled wherever it is not required.
TLS on the load balancer and between instances
HTTPS should terminate on the load balancer with certificates issued and renewed through your own process, and the Fineract documentation encourages HTTPS only through settings such as FINERACT_SERVER_SSL_ENABLED. Decide whether traffic from the load balancer to each instance is encrypted, and apply the same rule to database and broker connections. Check certificate expiry monitoring for every hop, because a lapsed certificate on one internal path can take down a read tier that looks healthy from outside.
Read replicas reachable from the wrong segment
The most common HA exposure is a read replica that answers on a network segment it was never meant to serve, such as a development subnet or a reporting tool's range. Map every listening database and broker address, then test reachability from each segment that should be excluded. Keep the full control set, including audit logging and access reviews, in the Fineract security hardening topic.
How to prove failover works before go-live
Failover is not proven by a design diagram. Before a Fineract deployment carries live accounts, the team should run a scripted set of failure tests against the actual topology, with the actual load balancer, database tooling and batch configuration, and record what happened. The first test targets the write instance. While a posting transaction, such as a loan repayment or a savings deposit, is in flight, stop the write instance process, let the load balancer and health checks react, restart the instance, and then query the ledger and the affected accounts. The pass condition is simple to state and easy to get wrong: each transaction appears exactly once, or not at all, and no journal entry is duplicated after a client retries the request. Confirm how your client retry behavior and idempotency handling behave in this path before the test, because a clean result depends on it. The second test fails the primary PostgreSQL database and promotes a replica using the tooling your team has chosen, whether that is a managed service feature or a self-managed cluster manager. Measure what the write instance does during the switch. It should reconnect to the new primary using the configured connection settings, without a manual restart, and it should resume writes only after Liquibase state and tenant connections are confirmed healthy. Also check that the tenants database entries still point to the correct databases after promotion. Do not accept a promotion that works only because an operator edited a connection string by hand during the test. The third test stops the batch instance in the middle of a Close of Business run. The Spring Batch job should either resume from its last committed step or be rerun safely. Verify this against the job execution records, not against the absence of errors. Check for double-applied interest, duplicate fee charges and accounting entries that appear twice. If remote partitioning is used, also stop one worker node and confirm the coordinating messages in ActiveMQ or Kafka are not lost. The fourth test removes a read instance from rotation and confirms that read traffic moves to the remaining instances without errors reaching staff screens or integrations. The fifth test measures replica lag during a peak read window. Compare the observed lag with the maximum your business has written down for reporting and customer balance views. If that maximum has not been agreed, agree it before testing, because a test without a threshold cannot fail. Keep evidence that an auditor or regulator can follow: the test plan with a named owner, the exact software versions and configuration under test, timestamps for each injected failure, database and batch logs, the query results that prove the ledger state, and a signed record of the result. A failed test blocks go-live. Examples include any duplicate posting, any batch step that is applied twice, a write instance that needs manual intervention to reconnect, or replica lag above the agreed limit at peak. A test that passes only after a workaround is treated as a failure until the design or runbook is corrected and the test is repeated.
What to monitor, back up and document after go-live
This sequence sets up the ongoing runbook for a highly available Fineract deployment, so the team can detect replication, batch and pool problems early, prove backups can be restored, and keep operating procedures accurate through each quarterly release.
Monitor replica lag and read instance health
Set alerts on PostgreSQL replication lag between the primary and each read replica, and on health checks for every Fineract read, write and batch instance. Read traffic should only reach replicas that are current enough for the screens and reports that use them, so confirm with your product owners what staleness is acceptable for each read path before setting thresholds. Done means each alert has a named owner, a tested notification route, and a documented response that tells the on-call engineer whether to pull a replica out of the load balancer.
Track connection pool use per instance role
Watch database connection pool utilization separately for write, read and batch instances, because each role places different demand on PostgreSQL. A batch instance that holds connections during a long run can starve interactive traffic if pools are shared or sized poorly. Review pool settings with your DBA and record the agreed ceiling per role. Done means dashboards show per-role pool use over a full business cycle, and the team has a documented action for when a pool approaches its ceiling.
Trend batch duration and alert on failed jobs
Record the duration of each Close of Business run and chart the trend against account volume, since the job can run for hours on large deployments and slows as data grows. Alert on failed or stalled jobs and on runs that exceed the duration your operations team has agreed. If remote partitioning is used, confirm that worker failures are visible to the batch owner. Done means a week of baseline runs is recorded, alerts reach the batch owner, and a failed run has a documented restart procedure that has been rehearsed in a non-production environment.
Schedule and test database backups separately
Configure point-in-time or scheduled backups of the primary database and of the tenants database, and store them outside the replication path. Replication copies errors, including accidental deletes, bad migrations and corrupted batch output, to every replica within moments, so replicas are not backups. Done means backup jobs are scheduled with retention set by your compliance owner, and each backup job reports success to the same monitoring as the other alerts.
Prove restores on a schedule
Restore a recent backup into an isolated environment on a regular schedule, then run a reconciliation check of client counts, loan balances and ledger totals against the documented expected values. A backup that has never been restored is an assumption, not a control. Done means each restore test produces a dated result record showing the backup used, the restore duration measured, and the reconciliation outcome, signed off by the platform owner.
Document failover, role owners and the upgrade gate
Write the failover procedure as a step-by-step runbook covering promotion of a replica, repointing the write instance, and how batch is paused and resumed. Name a single owner for each role (write, read, batch, database, identity, on-call rota) with a documented contact route. Record the Liquibase upgrade gate, which states that migrations run only on write instances and that a restore test must pass before any migration in production. Done means every role has a named owner and a working contact, and a tabletop exercise has walked through the failover steps.
Review runbook accuracy after each quarterly release
Fineract publishes official releases quarterly, so schedule a runbook review at each release. Check configuration variables, monitoring metric names, Liquibase behavior and any changed batch settings against the release notes and the Fineract documentation, then test the changed steps in a staging environment. Done means the review is recorded with the release version reviewed, each changed step is updated or confirmed, and the on-call rota has acknowledged the new version of the runbook.
Questions buyers ask before hiring help for Fineract high availability
Can our own team build Fineract high availability without a partner?
Yes, if your team already runs PostgreSQL replication, load balancers and Java services in production and has the time to design and test the failover path. Apache Fineract is open source under the Apache License 2.0, so there is no license fee, but the project's README warns that a production deployment can be complex, costly and time-consuming and that it does not provide a comprehensive production deployment guide. The honest test is whether you have engineers who can separate read, write and batch instances, rehearse a database failover and verify that Close of Business still completes after a node loss. A partner usually adds value when those skills are thin or the timeline is short. Ask whether you want the design only, the build, or both.
How long does a Fineract high availability project take, and what sets the duration?
Duration depends on your starting point rather than on a single standard figure, and no fixed timeline applies to every institution. The main drivers are the number of Fineract instances you plan to run, whether PostgreSQL replication already exists, how many environments you must rebuild (development, test, pre-production and production), and how much failover testing your risk function requires. Account volume matters too, because the Close of Business batch job can run for several hours on deployments with millions of accounts, so batch design and timing tests take longer at scale. Ask any provider for a written schedule that lists each test cycle and the environment it runs in.
What does a high availability build need from our database, network and operations teams?
Your database team owns the PostgreSQL primary, the streaming replicas used for read instances, backup and failover tooling, and the connection settings Fineract uses. Your network team owns the load balancer, health checks, TLS termination, firewall rules between application tiers and the database, and any routing to a second site. Operations owns monitoring, alerting on batch job status, runbooks, on-call coverage and change control for upgrades. Liquibase schema migrations run only on write instances, so operations must agree on when migrations are applied. Before scoping, confirm with each team the current replication topology, recovery time and recovery point targets your bank has already approved, and their maintenance windows.
How much does Fineract high availability cost, and what is one-time versus recurring?
Fineract itself has no license fee, so cost comes from infrastructure, people and services. One-time costs usually include architecture design, building the environments, configuring replication and load balancing, batch partitioning setup, failover rehearsals and documentation. Recurring costs include database and application hosting for every instance, replica storage, backups, monitoring, on-call staffing and any retainer for upgrades and support. Costs rise with the number of read instances, the size of the database, the number of regions, and the depth of testing. Ask for each cost line in your quote to show who pays for it, whether it is one-time or monthly, and which assumptions it depends on, such as instance counts and data volume.
Does Apache Fineract provide built-in automatic failover?
The Fineract documentation describes instance types set by environment variables (read, write and batch) and recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. It does not present these as an automatic failover system. Database failover, health-based routing and promotion of a standby batch node are handled by your database platform, load balancer and orchestration layer. Confirm the exact behavior of your chosen Fineract version and your PostgreSQL tooling in a test environment before relying on it, and confirm with the vendor of any managed database or orchestrator how failover is triggered and how long clients may see errors.
What should a fixed-scope quote for Fineract high availability list?
A fixed-scope quote should name each deliverable and the environment it applies to. Look for the target topology (number of write, batch and read instances), the PostgreSQL replication and failover approach, load balancer and health check design, the Close of Business plan including whether remote partitioning through ActiveMQ or Kafka is in scope, monitoring and alerting, security settings such as HTTPS and changed default credentials, failover test scenarios with pass criteria, runbooks, knowledge transfer, and handover. It should also state assumptions the provider needs from you, such as access, environments and staff time, plus what is excluded, like application customization or upgrades after go-live. Ask for the schedule and the named responsibilities on both sides.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports Apache Fineract high availability inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Each step, from the first scoping conversation to ongoing support, follows a written scope agreed before work starts.
How we scope
- Confirm the instance layout: one write instance, one batch instance and the read instances your reporting and customer load requires.
- Map the PostgreSQL topology, including replication mode, read replica count, failover expectations and backup location.
- Agree the Close of Business approach, including whether the nightly batch job needs remote partitioning across workers using ActiveMQ or Kafka.
How we build
- Deploy separate write, batch and read instances with environment-variable configuration, and place read traffic on database read replicas.
- Configure load balancing so write requests reach only the write instance, and confirm Liquibase migrations run there and nowhere else.
- Test failover, instance restarts and batch completion under realistic volumes, and record the results against the agreed scope.
How we hand over
- Provide architecture diagrams, configuration inventory and runbooks for failover, scaling and restoring the PostgreSQL cluster.
- Document Close of Business monitoring, alert thresholds and the steps an operator follows when a batch run does not complete.
- Walk your platform and database teams through the deployment and transfer administrative access to your own accounts.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, and agree its coverage in writing alongside the original scope.
- Review each quarterly Fineract release for changes affecting instance roles, database migrations or batch behavior before you upgrade.
- Repeat failover and batch tests after upgrades, infrastructure changes or growth in account volumes, and report the findings to your team.
