Get Appointment

contact@wellinor.com
+(123)-456-7890

Blog & Insights

Software has moved well beyond its back-office origins. For most organizations today, it's the product, the primary customer touchpoint, or the system determining whether an order ships on time. As the stakes attached to application decisions continue to rise, so does the cost of getting them wrong.

Many organizations face an additional challenge: managing an older platform that still carries essential business logic, one that current staff no longer fully understand. Whether you're building something new or carrying an existing system forward, application development is what determines whether software becomes a long-term business asset or an accumulating liability.

We design, build, and modernize applications for organizations that depend on their software to perform reliably under real business pressure. The starting point differs from one engagement to the next, but the underlying discipline does not.

Discovery and Understanding: Where the Real Work Begins

A significant share of application projects go wrong before a single line of code is written. The problem the system was meant to solve was never fully understood in the first place. Engagements begin with the people who will actually use and depend on the system, rather than a predetermined list of assumed features. Time invested in discovery reduces the risk of building the wrong thing quickly and having to rebuild it later at greater cost.

Architecture receives the same level of attention. Transaction volume, regulatory requirements, and the way a system needs to interact with everything around it all inform the technical approach. Rather than defaulting to whichever pattern happens to be familiar or currently popular, we design based on actual need. A payment platform and an internal reporting tool carry different demands, even when it would be simpler to design them the same way.

Modernizing Legacy Systems: The Hidden Knowledge Problem

Legacy systems tend to carry more institutional knowledge than they appear to on the surface. A platform that has been in production for fifteen or twenty years typically encodes a substantial number of business rules that were never formally documented. Many were established through past incidents the organization has no interest in repeating.

Before any component is replaced, we invest time in understanding what the code is actually doing. This is often a different question than what the existing documentation describes. Modernization that skips this step risks discarding logic that was quietly load-bearing. This gap tends to surface only after the new system is already in production.

This is one reason engagements are delivered in stages rather than as a single large cutover. A comprehensive rewrite delivered all at once depends on every assumption being correct from the outset. This is rarely the case in practice. Delivering in smaller, working increments allows the business to see progress along the way, identify issues while they remain inexpensive to correct, and adjust direction before significant effort has been committed to a flawed assumption.

Data migration follows the same principle. Data is mapped, validated, and reconciled as it moves between systems. A migration that is technically complete but has quietly introduced data integrity issues has not truly succeeded, even if it appears to have.

Critical Considerations Often Overlooked

Integration Design Matters from Day One

Very few applications operate in isolation. A system that cannot integrate cleanly with the environment around it tends to become disconnected within a relatively short period. This requires additional work later to reconnect it, typically under less favorable conditions than if the integration had been designed in from the outset.

Quality Assurance Isn't a Final Step

Testing is subject to similar pressure, often deprioritized as deadlines approach. Building quality assurance into the development process from the beginning allows issues to be identified while they remain inexpensive to resolve. It also gives teams the confidence to release changes at a sustainable pace.

Modern Infrastructure Requires Modern Architecture

When a legacy system moves to modern infrastructure, the objective extends beyond relocation. Re-architecting the system to take genuine advantage of what a modern, cloud-native platform provides is what allows the application to scale with the business. Without this consideration, it becomes a constraint on growth instead.

How We Approach Custom Application Development

Most organizations we work with already employ capable engineers. What is typically in shorter supply is sufficient capacity, whether measured in headcount or available time. These constraints make it difficult to take on a substantial build or modernization initiative without disrupting existing priorities. This is generally where our engagement begins: working alongside your existing team rather than in place of it.

Your engineers remain engaged for the duration of the project, well beyond the initial kickoff. Knowledge is transferred in both directions. By the conclusion of the engagement, your team should understand the system well enough to operate it, extend it, and explain it to future hires. Every engagement includes formal training and documentation to support that outcome. A system your organization does not fully understand becomes its own form of technical debt over time.

Scope, Security, and Sustainable Success

We maintain transparency around scope. In some cases, a full rebuild is genuinely the right answer. In many others, a smaller and more targeted solution addresses the underlying business need. Part of working responsibly means recommending that option even when a larger engagement would be more advantageous to us commercially.

Progress is evaluated against whether the actual business problem is being resolved. This happens through regular conversations with the people who will ultimately depend on the result. Rather than tracking solely through delivery metrics that can appear favorable right up until launch and prove otherwise afterward, we focus on outcomes that matter.

Security is treated as an integral part of development rather than a separate, later phase. Depending on the industry and the sensitivity of the data or transactions involved, this typically includes secure coding practices, access controls, and applicable compliance requirements addressed from the earliest stages of the project. The team responsible for planning the work is also the team that builds and supports it. Recommendations are grounded in prior delivery experience rather than theoretical best practice.

Application Development Across Industries

Our teams have delivered this kind of work in financial services, retail, industrial and agricultural operations, and healthcare. We've worked on systems ranging from customer-facing platforms processing significant transaction volume to internal tools that never reach an end customer directly. Regulatory requirements and tolerance for downtime vary meaningfully across these industries, but the underlying approach remains consistent.

If your organization is evaluating a new build, a modernization initiative, or simply needs additional capacity on something business-critical, we would welcome the conversation.

[table id=3 /]

Keyva is pleased to announce the certification of the Keyva BMC Atrium Data Pump for the new ServiceNow Australia release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Zurich, Yokohama, Xanadu) to the Australia release.

The ServiceNow Australia release delivers enhanced AI-driven workflows, improved user experiences, and expanded automation capabilities to increase productivity, resilience, and service efficiency across the enterprise.

Keyva's BMC Atrium Data Pump provides synchronization of CIs, CI attributes, and relationships from the BMC Atrium CMDB into the ServiceNow CMDB. This integration allows organizations to leverage their existing investment in Enterprise Software and avoid costly "Rip and Replace" projects.

Learn more about the Keyva BMC Atrium Data Pump and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva BMC Atrium Data Pump BMC to ServiceNow Certified for Australia Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-bmc-atrium-data-pump-certified-for-australia-release [to_ping] => [pinged] => [post_modified] => 2026-09-03 14:10:51 [post_modified_gmt] => 2026-09-03 14:10:51 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5327 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 5324 [post_author] => 15 [post_date] => 2026-09-04 13:57:23 [post_date_gmt] => 2026-09-04 13:57:23 [post_content] =>

Keyva is pleased to announce the certification of the Keyva HP Universal CMDB Data Pump for the new ServiceNow Australia release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Zurich, Yokohama, Xanadu) to the Australia release.

Keyva's HP Universal CMDB Data Pump provides synchronization of CIs, CI attributes, and relationships from the ServiceNow CMDB into the HP Universal CMDB. This integration allows organizations to leverage their existing investment in Enterprise Software and avoid costly "Rip and Replace" projects.

Learn more about the Keyva HP Universal CMDB Data Pump and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva HP Universal CMDB Data Pump Certified for Australia Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-hp-universal-cmdb-data-pump-certified-for-australia-release [to_ping] => [pinged] => [post_modified] => 2026-09-03 14:10:37 [post_modified_gmt] => 2026-09-03 14:10:37 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5324 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 5335 [post_author] => 15 [post_date] => 2026-09-03 14:09:35 [post_date_gmt] => 2026-09-03 14:09:35 [post_content] =>

Keyva is pleased to announce the certification of the Keyva VMware Orchestration for the new ServiceNow Australia release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Zurich, Yokohama, Xanadu) to the Australia release.

Keyva's VMware Orchestration allows users to trigger VMware operations directly from ServiceNow Catalog Requests, Change Requests, Incident Requests, and more. Users have the flexibility to configure custom triggers and define specific conditions for launch, ensuring that any approvals established within ServiceNow are completed before the corresponding VMware operation is initiated. This integration allows organizations to fulfill infrastructure automation requests through VMware from a centralized ServiceNow service catalog, without requiring additional ServiceNow licensing.

Learn more about the Keyva VMware Orchestration and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva VMware Orchestration Certified for Australia Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-vmware-orchestration-certified-for-australia-release [to_ping] => [pinged] => [post_modified] => 2026-09-03 14:34:41 [post_modified_gmt] => 2026-09-03 14:34:41 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5335 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [4] => WP_Post Object ( [ID] => 5299 [post_author] => 15 [post_date] => 2026-09-02 14:11:08 [post_date_gmt] => 2026-09-02 14:11:08 [post_content] => Every one of the Sysbox install steps assumes the underlying node pool is already shaped correctly. It isn't, by default, and figuring that out the hard way costs more time than reading about it up front. Trying to troubleshoot a DaemonSet that keeps failing silently on nodes that is never going to work. The first surprise is the node image. GKE hands you Container Optimized OS by default, which is a reasonable choice for almost every other workload on the cluster. Sysbox needs Ubuntu though, and specifically a kernel at 5.4 or newer, which COS simply doesn't provide. So, the first real prerequisite isn't a Sysbox setting at all. It's provisioning a separate node pool that actually runs Ubuntu with containerd, using the UBUNTU_CONTAINERD image type, rather than assuming the default pool will work. Sizing is the second thing teams underestimate. A node running nested Docker daemons inside user namespaces needs genuine headroom, not the smallest instance that technically boots. Four vCPUs and 4GB of RAM per node is closer to a floor than a comfortable target, and going below it doesn't throw a clean error. It just shows up later as sandboxes that intermittently fail to start. Version alignment is where things get quietly wrong. Sysbox wants Kubernetes 1.32 or newer, running alongside containerd 2.0.5 or later. There's a specific range, containerd 2.0.1 through 2.0.4, carrying a bug that blocks pods from launching under any non-default runtime, Sysbox included. Land a node pool in that range and the installer falls back to deploying its own CRI-O runtime and switching the node over, which restarts kubelet and disrupts running pods for a minute or two. Survivable, but not something worth discovering by accident on a cluster other teams depend on. Pin the node pool version on purpose instead of letting a release channel decide for you. The last piece is scheduling. The Sysbox installer looks for a specific label, sysbox-install=yes, before it will touch a node, and in practice a taint is worth adding too, so nothing lands on that node except workloads that actually want Sysbox underneath them. Both belong in the same Terraform that provisions the pool, not in a kubectl command someone runs once during setup and never writes down again. Here's roughly what that node pool looks like in practice:

resource "google_container_node_pool" "sysbox_pool" {
  name       = "sysbox-nodes"
  cluster    = google_container_cluster.primary.name
  location   = google_container_cluster.primary.location
  node_count = 2
  version    = "1.32.4-gke.1236000"
 
  node_config {
    machine_type = "e2-standard-4"
    image_type   = "UBUNTU_CONTAINERD"
    disk_size_gb = 100
 
    labels = {
      "sysbox-install" = "yes"
    }
 
    taint {
      key    = "sysbox"
      value  = "true"
      effect = "NO_SCHEDULE"
    }
 
    oauth_scopes = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]
  }
 
  management {
    auto_repair  = true
    auto_upgrade = false
  }
}

The image_type line does most of the real work here. Everything else is tuning around it. Get that node pool right and the rest of the install, labeling the node, applying the manifest, watching the DaemonSet come up healthy, turns into the straightforward part it's supposed to be. None of this is complicated once it's written down. It's just the kind of setup that stays invisible when done correctly and expensive when skipped, which is probably why it rarely gets more than a passing mention in the official documentation. [table id=3 /] [post_title] => Before You Install Sysbox, GKE Has to Be Ready For It [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => before-you-install-sysbox-gke-has-to-be-ready-for-it [to_ping] => [pinged] => [post_modified] => 2026-09-03 14:11:19 [post_modified_gmt] => 2026-09-03 14:11:19 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5299 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 5321 [post_author] => 15 [post_date] => 2026-09-01 13:54:37 [post_date_gmt] => 2026-09-01 13:54:37 [post_content] =>

Keyva is pleased to announce the certification of the Keyva Service Integration Hub for Red Hat Ansible Automation Platform for the new ServiceNow Australia release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Zurich, Yokohama, Xanadu) to the Australia release.

Keyva's Service Integration Hub for Red Hat Ansible Automation Platform allows users to initiate and manage Ansible automation tasks directly from ServiceNow Catalog Requests, Change Requests, and more. Users have the flexibility to configure custom triggers and define specific conditions for launch, ensuring that any approvals established within ServiceNow are completed before the corresponding Ansible job is initiated. This integration allows organizations to fulfill IT automation requests through Ansible Automation Platform from a centralized ServiceNow service catalog, without requiring additional ServiceNow licensing.

Learn more about the Keyva Service Integration Hub for Red Hat Ansible Automation Platform and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva Service Integration Hub for Red Hat Ansible Automation Platform Certified for Australia Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-service-integration-hub-for-red-hat-ansible-automation-platform-certified-for-australia-release [to_ping] => [pinged] => [post_modified] => 2026-09-03 14:10:19 [post_modified_gmt] => 2026-09-03 14:10:19 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5321 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [6] => WP_Post Object ( [ID] => 5318 [post_author] => 15 [post_date] => 2026-08-29 13:54:15 [post_date_gmt] => 2026-08-29 13:54:15 [post_content] =>

Keyva is pleased to announce the certification of the Keyva Service Integration Hub for Red Hat OpenShift for the new ServiceNow Australia release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Zurich, Yokohama, Xanadu) to the Australia release.

Keyva's Service Integration Hub for Red Hat OpenShift allows users to trigger Red Hat OpenShift build jobs directly from ServiceNow Catalog Requests, Change Requests, Incident Requests, and more. Users have the flexibility to configure custom triggers and define specific conditions for launch, ensuring that any approvals established within ServiceNow are completed before the corresponding OpenShift deployment job is initiated. This integration allows organizations to fulfill IT automation requests through OpenShift from a centralized ServiceNow service catalog, without requiring additional ServiceNow licensing.

Learn more about the Keyva Service Integration Hub for Red Hat OpenShift and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva Service Integration Hub for Red Hat OpenShift Certified for Australia Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-service-integration-hub-for-red-hat-openshift-certified-for-australia-release [to_ping] => [pinged] => [post_modified] => 2026-09-03 14:10:04 [post_modified_gmt] => 2026-09-03 14:10:04 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5318 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [7] => WP_Post Object ( [ID] => 5294 [post_author] => 15 [post_date] => 2026-08-27 20:09:42 [post_date_gmt] => 2026-08-27 20:09:42 [post_content] => Have you ever lost work because of an error done while using Git? Perhaps by deleting an unpushed branch by mistake, or having done a hard reset on the wrong repository? A destructive error could mean hours of reconstruction, unless you’re aware that Git has a feature meant for recovery from this sort of mistake. This feature is known as the reference log, or "reflog" for short. The reflog is your local record of where your branch pointer is, and where it has been in recent history. Every time a change to a branch pointer happens, Git remembers the position. It should be noted that the reflog is local to specific clones. Short of packing up the .git folder and sending it to a colleague, doing a recovery via the reflog needs to be done on the copy that the error was done on. So, what exactly does the reflog track, and what does it not? As mentioned, branch pointers are tracked, but so are remote tracking branch updates, HEAD movements and stashes. A list of common operations this includes are:

clone (will be the initial state until it falls out of history)
pull (a merge done as a part of a pull step will add an additional entry)
commit (including separate instances of --amend)
checkout
stash
merge
rebase
reset

Most importantly, what the reflog does not track are changes that were never staged or committed. The key takeaway for this being: stage/commit your code often; don’t allow large monolithic deltas to catch you off-guard.

Basic Operations

Interacting with the reference log is done via the `git reflog` command. Here is an example reflog output:

ebe1ad46f (HEAD -> dev, origin/dev) HEAD@{0}: commit: Build and Run on MacOS

3fb7c8ff4 HEAD@{1}: pull: Fast-forward

f9d877784 HEAD@{2}: commit: Fixing contrib dead linkage

372bbea2b HEAD@{3}: reset: moving to origin/dev

372bbea2b HEAD@{4}: checkout: moving from master to dev

3b6a7e870 (origin/master, origin/HEAD, master) HEAD@{5}: clone: from <repo URL>

Each entry shows, in order:

The commit hash that the reference points to
The reference name (e.g. this case "HEAD", "dev" [local branch], "origin/dev" [remote branch])
Position information within curly braces (e.g. {4}) indicating how many steps back
Action with git command used to cause the change, and a brief description of the change

Reference logs for specific branches can also be done:

$ git reflog show master

3b6a7e870 (origin/master, origin/HEAD, master) master@{0}: clone: from <repo URL>

As well as timestamps:

$ git reflog show master --relative-date # Also try --date=iso

3b6a7e870 (origin/master, origin/HEAD, master) master@{7 weeks ago}: clone: from <repo URL>

And even with patches displayed as part of the output:

$ git reflog show master --relative-date -p

3b6a7e870 (origin/master, origin/HEAD, master) master@{7 weeks ago}: clone: from <repo URL>

diff --git a/src/app/app.cpp b/src/app/app.cpp

index 7833fae15..6da32d596 100644

--- a/src/app/app.cpp

+++ b/src/app/app.cpp

@@ -33,7 +33,7 @@ static void SetCompleted(App *_app, bool &_) { App::s_isCompleted = _isCompleted; }
-App::Model *App::s_model = save::g_appFormatter.RegisterModel<App>(

+App::Model *App::s_model = save::ModelStorage::RegisterModel<App>(

APP_STRINGIFY(App),

save::AttributeAccess<&App::m_loadedSavefileVer,

Common scenarios

Now that we have some understanding of what we’re looking at with the reference log output, let’s go over some scenarios. Example 1: Accidental use of `reset --hard`:

$ git reset --hard HEAD~3

# Oops.
$ git reflog

8a91155e0 (HEAD -> dev) HEAD@{0}: reset: moving to HEAD~3

ebe1ad46f (origin/dev) HEAD@{1}: commit: Build and Run on MacOS

[...]

# Now we use the commit before the reset (ebe1ad46f HEAD@{1})
$ git reset --hard ebe1ad46f # using "HEAD@{1}" in place of the hash is also acceptable

And we have effectively undone a hard reset. Note that in doing this, the first hard reset (the 8a91155e0 hash) is still present in the reference log and is now the new HEAD@{1}.

Example 2: Lost commit from a rebase

$ git rebase -i HEAD~5

Successfully rebased and updated refs/heads/dev.

# We need that last commit, however...

$ git reflog

0d9cae3c1 (HEAD -> dev) HEAD@{0}: rebase (finish): returning to refs/heads/dev

0d9cae3c1 (HEAD -> dev) HEAD@{1}: rebase (start): checkout HEAD~5

ebe1ad46f (origin/dev) HEAD@{2}: commit: Build and Run on MacOS

# Now we can cherry-pick the hash of the needed commit

$ git cherry-pick ebe1ad46f


# Don’t forget to commit!

Example 3: Mistakenly deleted branch

$ git checkout master

M               .gitignore

M               .gitmodules

[...]

Switched to branch 'master'

Your branch is up to date with 'origin/master'.


$ git branch -D dev

Deleted branch dev.

# Oops again.

$ git reflog

3853c23ba (HEAD -> master, origin/master) HEAD@{0}: checkout: moving from dev to master

ebe1ad46f (origin/dev) HEAD@{1}: commit: Build and Run on MacOS

[...]

# We can recreate the branch in whole from the last state we saw that branch in

$ git checkout -b dev ebe1ad46f

M               .gitignore

M               .gitmodules

[...]

Switched to a new branch 'dev'

One Final Note

It is important to know that the reference log does not, by default, hold all history forever. Depending on the situation, entries will expire within 30 or 90 days. This behaviour can be changed via:

# You can also use "never" to keep everything or "now" to not keep a log (strongly discouraged)

# You can also make this affect all repos you use with --global

$ git config gc.reflogExpire 365.days
$ git config gc.reflogExpireUnreachable 90.days

Ultimately, the reference log serves well as a light in the dark, should things go wrong. These are some common examples, but most destructive operations short of deleting the .git folder can be recovered, from bad amends on commits to merges gone awry.

References and Additional Reading:

https://git-scm.com/docs/git-reflog
https://git-scm.com/docs/git-gc (for cleanup/pruning of the reference log)

[table id=11 /] [post_title] => Gitting Good – Leveraging the Reference Log For Disaster Recovery [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => gitting-good-leveraging-the-reference-log-for-disaster-recovery [to_ping] => [pinged] => [post_modified] => 2026-08-27 20:10:16 [post_modified_gmt] => 2026-08-27 20:10:16 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5294 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 8 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 5350 [post_author] => 15 [post_date] => 2026-09-09 16:29:47 [post_date_gmt] => 2026-09-09 16:29:47 [post_content] =>

Discovery and Understanding: Where the Real Work Begins

Modernizing Legacy Systems: The Hidden Knowledge Problem

Critical Considerations Often Overlooked

Integration Design Matters from Day One

Quality Assurance Isn't a Final Step

Modern Infrastructure Requires Modern Architecture

How We Approach Custom Application Development

Scope, Security, and Sustainable Success

Application Development Across Industries

If your organization is evaluating a new build, a modernization initiative, or simply needs additional capacity on something business-critical, we would welcome the conversation.

[table id=3 /]

[post_title] => Application Development and Software Modernization: Building Systems That Drive Business Results [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => application-development-and-software-modernization [to_ping] => [pinged] => [post_modified] => 2026-09-09 16:29:47 [post_modified_gmt] => 2026-09-09 16:29:47 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5350 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 171 [max_num_pages] => 22 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => c0ac5b645bca5e8a351ed08806ccbf53 [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [allow_query_attachment_by_filename:protected] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) [query_cache_key:WP_Query:private] => wp_query:cb46a272b3f31498c88060117c9a6915 [tribe_is_event] => [tribe_is_multi_posttype] => [tribe_is_event_category] => [tribe_is_event_venue] => [tribe_is_event_organizer] => [tribe_is_event_query] => [tribe_is_past] => )