Get Appointment

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

Blog & Insights

WP_Query Object ( [query] => Array ( [post_type] => post [showposts] => 8 [orderby] => Array ( [date] => desc ) [autosort] => 0 [paged] => 0 [post__not_in] => Array ( [0] => 5233 ) ) [query_vars] => Array ( [post_type] => post [showposts] => 8 [orderby] => Array ( [date] => desc ) [autosort] => 0 [paged] => 0 [post__not_in] => Array ( [0] => 5233 ) [error] => [m] => [p] => 0 [post_parent] => [subpost] => [subpost_id] => [attachment] => [attachment_id] => 0 [name] => [pagename] => [page_id] => 0 [second] => [minute] => [hour] => [day] => 0 [monthnum] => 0 [year] => 0 [w] => 0 [category_name] => [tag] => [cat] => [tag_id] => [author] => [author_name] => [feed] => [tb] => [meta_key] => [meta_value] => [preview] => [s] => [sentence] => [title] => [fields] => all [menu_order] => [embed] => [category__in] => Array ( ) [category__not_in] => Array ( ) [category__and] => Array ( ) [post__in] => Array ( ) [post_name__in] => Array ( ) [tag__in] => Array ( ) [tag__not_in] => Array ( ) [tag__and] => Array ( ) [tag_slug__in] => Array ( ) [tag_slug__and] => Array ( ) [post_parent__in] => Array ( ) [post_parent__not_in] => Array ( ) [author__in] => Array ( ) [author__not_in] => Array ( ) [search_columns] => Array ( ) [ignore_sticky_posts] => [suppress_filters] => [cache_results] => 1 [update_post_term_cache] => 1 [update_menu_item_cache] => [lazy_load_term_meta] => 1 [update_post_meta_cache] => 1 [posts_per_page] => 8 [nopaging] => [comments_per_page] => 50 [no_found_rows] => [order] => DESC ) [tax_query] => WP_Tax_Query Object ( [queries] => Array ( ) [relation] => AND [table_aliases:protected] => Array ( ) [queried_terms] => Array ( ) [primary_table] => wp_posts [primary_id_column] => ID ) [meta_query] => WP_Meta_Query Object ( [queries] => Array ( ) [relation] => [meta_table] => [meta_id_column] => [primary_table] => [primary_id_column] => [table_aliases:protected] => Array ( ) [clauses:protected] => Array ( ) [has_or_relation:protected] => ) [date_query] => [request] => SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.ID NOT IN (5233) AND ((wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'expired' OR wp_posts.post_status = 'acf-disabled' OR wp_posts.post_status = 'tribe-ea-success' OR wp_posts.post_status = 'tribe-ea-failed' OR wp_posts.post_status = 'tribe-ea-schedule' OR wp_posts.post_status = 'tribe-ea-pending' OR wp_posts.post_status = 'tribe-ea-draft'))) ORDER BY wp_posts.post_date DESC LIMIT 0, 8 [posts] => Array ( [0] => WP_Post Object ( [ID] => 5268 [post_author] => 7 [post_date] => 2026-06-30 14:09:24 [post_date_gmt] => 2026-06-30 14:09:24 [post_content] => Perhaps you're testing across multiple machines and don't want to push incomplete code. Maybe you're working with a collegue on a particularly long flight. Or perhaps your main repository has become unreachable, and you don't know when it will be back. At its core, Git is designed to not require a central service or authority to work. This might come as something of a surprise, since most projects use a central authority such as GitHub, GitLab or BitBucket. However, within your pulled repository exists a complete history of your pulled branch's changes, from the very first commit. Because of this, any machine can act as a Git server. This can be leveraged even with the general internet unavailable; no special services or daemons are required. Not even a reliable network connection is required, so long as your have a USB drive handy. All that you need between two computers is both having git, and both able to communicate in some way. ## Option 1 - Bare repo on shared media Those of us who collaborated with others in a pre-internet world know the usefulness of sneakernet. For the rest who are unaware, this is basically comprised of adding your data to media storage (these days, probably a USB drive) and phyiscally walking it over to where it needs to be. This is perhaps the simplest way to get around a downed service issue [xxx - revisit, don't like wording]. To do this, first we initialize a bare repo on our media: ``` cd /media/usb git init --bare repo.git ``` Then, we can add this path as a remote to push to ``` cd ~/src/repo git remote add usb-stick /media/usb/repo.git git push usb-stick main ``` Finally, we unmount the USB and bring it to the target machine and run the same setup before pulling: ``` cd ~/src/repo git remote add usb-stick /media/usb/repo.git git pull usb-stick main ``` Now, in order to sync later, the chosen media can be passed back and forth as your temporary central repository. If you only need to pass a repository and not later share history, an even simpler cludgel is available. With the above example, `/media/usb/repo.git` is effectively a copy of `~/src/repo/.git`. It would also be possible to simply: ``` cp -r ~/src/repo/.git /media/usb/repo.git ``` Then, on the target machine: ``` mkdir ~/src/repo ~/src/repo/ cp -r /media/usb/repo.git ~/src/repo/.git git reset --hard ``` At this point, you have a carbon copy of the history and a working source directory. Actually a bit better than the prior solution for initial sharing, because this method would share all branches on the source machine as well, instead of needing to individually push the same branches. ## Option 2 - Direct peer-to-peer over local IP It's also possible with a bridge, hotspot, or even just direct connection to do this over a two terminal network. In this example, we will assume that the source computer has an IP of 192.168.1.10 on this network. It's important to preface this by adding: don't do this outside of an isolated network as this makes your served repo readable to anyone on your network. It's the sort of solution meant for long car rides and international flights, not general use. On our source machine: ``` # Make our service path mkdir -p /srv/git && cd /srv/git # Init a bare repo git init --bare repo.git # Add this local repo to your remotes; like the USB method, we can simply use the path cd ~/src/repo git remote add local /srv/git/repo.git git push local main # Return to the service path and launch the git daemon cd /srv/git git daemon --base-path=. --export-all --reuseaddr --verbose --port=9418 ``` This invokes a lightweight, read-only service daemon that is built into git, running on git's default port of 9418. It requires no authentication, which is fine for our very small, isolated network. Then, our target can clone directly from this repository: ``` cd ~/src git clone git://192.168.1.10/repo.git ``` Best practices would have both machines running their own daemon, commiting and pushing to their local path and each machine pulling from each other. If it's more desirable however, one can also have our source machine act as a central authority. Again, not to be used outside an isolated network, and with additional peril, taht this method would allow not only readability to everything on the network, but writability as well. ``` # Before running `git daemon`: cd /srv/git/repo.git git config receive.denyCurrentBranch ignore # `warn` is also an option in place of `ignore` cd /srv/git # Note the addition of --enable=receive-pack git daemon --base-path=. --export-all --reuseaddr --verbose --port=9418 --enable=receive-pack ``` ## Option 3 - With SSH transport (most realistic for an office or VPN setting) If `sshd` is available, changes can be pushed directly using SSH without running any daemon. Note for MacOS: enable Remote Login in Sytem Settings -> General -> Sharing -> Advanced -> Remote Login For Linux: `systemctl start sshd` (assuming the sshd package is available) For Windows: You will require WSL, then installing the relevant package (most distros use the package `openssh-server`) and then port forwarding. This is beyond the scope of this guide, but it should be searchable, knowing what to look for. This will also likely require permissions handling, also beyond the scope of this guide. For Linux, search for how to add users and ssh public keys and group permissions with `chmod` or `setfacl`. As before, we will set up a directory for our repo and push to it normally: ``` # Make our service path mkdir -p /srv/git && cd /srv/git # Init a bare repo git init --bare repo.git # Add this local repo to your remotes; like the USB method, we can simply use the path cd ~/src/repo git remote add local /srv/git/repo.git git push local main ``` Then, for our target machine, we can clone directly as if a path over SSH: ``` git remote add machine1 ssh://user@192.168.1.10/srv/git/repo.git git pull machine1 main ``` If you wish to learn about more retro way of creating patch files (the method of choice for collaboration over email), I suggest looking into the offical documention for these methods https://git-scm.com/docs/git-bundle, https://git-scm.com/docs/git-send-email and https://git-scm.com/docs/git-format-patch. [table id=11 /] [post_title] => # Gitting Good - How to Colabborate Without a Central Service [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => gitting-good-how-to-colabborate-without-a-central-service [to_ping] => [pinged] => [post_modified] => 2026-06-30 14:09:24 [post_modified_gmt] => 2026-06-30 14:09:24 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5268 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 5264 [post_author] => 7 [post_date] => 2026-06-25 16:57:23 [post_date_gmt] => 2026-06-25 16:57:23 [post_content] => There's a version of AI adoption in IT ops that looks something like this: someone buys a Copilot license, attaches it to ServiceNow, and waits for the magic to happen. Three months later, the tickets are still messy, the on-call engineer is still waking up at 2 am, and nobody can explain why the AI recommended closing an incident that was still actively on fire. We've seen this pattern more times than we can count. And it's not a technology problem, it's an approach problem. The Gap Between "AI-Capable" and "AI-Useful" Infrastructure and operations teams aren't short on tools. Most have 150% of the tools they need. They have observability stacks, ITSM platforms, runbook documentation, and CI/CD pipelines generating telemetry constantly. The problem is that nobody has connected those data sources to an AI workflow in a way that actually reflects how the team works. One of our clients - a regional financial services firm - managing roughly 400 VMs across a hybrid AWS and on-prem footprint came to us after spending six months trying to get Azure OpenAI to summarize their PagerDuty alerts in a useful way. The summaries were technically accurate but operationally useless. They'd describe what happened with perfect clarity and say nothing about the why, and nothing about what the on-call engineer should do about it at midnight. The root cause wasn't the model. It was that nobody had connected the alert data to the runbooks, to the CMDB topology, or to the historical incident record, or the knowledge base. The AI was operating without context like asking a new hire to triage production issues on their first day without showing them the architecture diagram. What The Three Days of Workshop Actually Looks Like Our AI Enablement Workshop is a three-day, hands-on engagement. Not a training. Not a slide deck. We come in, work directly with your tools and your data, and leave with working prototypes and a prioritized roadmap. Day one is mostly listening. We sit with the platform engineering team, the SRE leads, and often someone from security. We ask a lot of questions about where the pain actually lives - not the official answer, but the real one. Alert fatigue is almost always on the list. So is the runbook problem. Most teams have documentation that's six months out of date (sometimes years out of date) and written in a way that only the person who wrote it can interpret quickly under pressure. We also audit data readiness. This is where most AI projects quietly fall apart. A Tier 2 incident with three lines of description and no attached logs is not a useful training signal. We look at what's actually in your ITSM system, what observability data can be queried, and whether the runbooks are in a format that a retrieval-augmented AI can actually use. Day two is where we build. Typically, we develop two or three use cases. The specific mix depends on what the team needs most. The most common starting point is an Incident Copilot: an AI-powered assistant that, when a P1 fires, automatically pulls the relevant alerts, correlates them with recent change activity, surfaces the most applicable runbook section, and produces a structured incident summary that goes directly into the ticket. For one manufacturing client, this took the average time-to-context – i.e. the point at which the on-call engineer actually understands what they're dealing with, from 18 minutes down to under 4. That's not a vendor benchmark. That's a number their SRE lead pulled from incident records after 4 weeks in production. We also commonly build a Runbook Assistant - a natural language interface over internal operational documentation. Engineers type a question in plain English, like "what do we do when the payments service is throwing 503s from the ALB?" And get a synthesized, sourced answer from the actual runbooks, not a hallucinated guess. The key engineering challenge here is retrieval quality and chunking strategy. Getting that wrong is what produces the confident-sounding wrong answers that erode trust in AI tools. Another key point to take away is that developing habits for optimizing tokens will help with making these tools cost efficient. Day three is architecture and roadmap. Where does this go in production? How does it connect to Teams or Slack for alert delivery? What are the human approval controls? What does the security and governance boundary look like, and who owns the ongoing prompt maintenance? Frankly Speaking Not every team is ready for day two on day one. We've walked into environments where the runbooks are in a SharePoint folder that hasn't been touched in two years, or where the observability data is rich but structured in a way that requires significant preprocessing before it's useful as AI context. That's fine, since part of what the workshop produces is clarity on what has to happen before scaling, not just what can be built right now. We also don't recommend automating things that shouldn't be automated yet. Ticket enrichment – i.e. automatically classifying, tagging, and augmenting incoming tickets before a human reviews them - is a very different risk profile from automated ticket resolution. We help teams think through that boundary clearly, and we're direct when we think a client is moving faster than their governance posture supports. What You Walk Away With After three days, teams have working prototypes built against their own data, a reusable codebase and prompt library, an architecture blueprint for production deployment, and a 30/60/90-day roadmap with use cases prioritized by effort versus operational impact. More practically, they have a team that has actually built something with AI, and not just watched a demo. They have a concrete sense of what AI can and cannot do in their environment. That last part matters more than people think. The biggest barrier to AI adoption in infrastructure operations isn't budget or tooling. It's the lack of a shared mental model across the team for what AI is actually good at and how to work with it. The workshop builds that model by doing, not by describing. Keyva delivers the AI Enablement Workshop for Infrastructure and Operations as a fixed-price, three-day engagement. If you're evaluating where AI can have the most immediate impact for your ops team, reach out at info@keyvatech.com. [table id=3 /] [post_title] => When AI Actually Works in IT Operations — And Why Most Teams Are Doing It Wrong [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => when-ai-actually-works-in-it-operations-and-why-most-teams-are-doing-it-wrong [to_ping] => [pinged] => [post_modified] => 2026-06-25 16:57:23 [post_modified_gmt] => 2026-06-25 16:57:23 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5264 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 5257 [post_author] => 7 [post_date] => 2026-06-11 09:37:02 [post_date_gmt] => 2026-06-11 09:37:02 [post_content] =>

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

The ServiceNow Zurich 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 v2.0.1 provides synchronization of CIs, CI attributes, and relationships from the ServiceNow CMDB into the BMC Atrium 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 Certified for Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-bmc-atrium-data-pump-servicenow-to-bmc-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-06-10 20:37:23 [post_modified_gmt] => 2026-06-10 20:37:23 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5257 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 5258 [post_author] => 15 [post_date] => 2026-06-10 20:36:53 [post_date_gmt] => 2026-06-10 20:36:53 [post_content] =>

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

The ServiceNow Zurich 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 HP Universal CMDB Data Pump provides synchronization of CIs, CI attributes, and relationships between the ServiceNow CMDB and 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 Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-hp-universal-cmdb-data-pump-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-06-10 20:36:53 [post_modified_gmt] => 2026-06-10 20:36:53 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5258 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [4] => WP_Post Object ( [ID] => 5256 [post_author] => 7 [post_date] => 2026-06-09 02:03:13 [post_date_gmt] => 2026-06-09 02:03:13 [post_content] =>

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

The ServiceNow Zurich 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 v3.2.1 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 Certified for Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-bmc-atrium-data-pump-bmc-to-servicenow-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-06-09 02:03:13 [post_modified_gmt] => 2026-06-09 02:03:13 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5256 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 5248 [post_author] => 15 [post_date] => 2026-06-01 15:09:46 [post_date_gmt] => 2026-06-01 15:09:46 [post_content] => Cloud environments grow fast, and so do bills. Without deliberate optimization, organizations routinely overspend by 20–40% on infrastructure that sits idle, is over-provisioned, or lacks lifecycle automation. The complexity of multiaccount, multi-cloud environments makes it nearly impossible to manage costs manually.

The Keyva Cloud Cost Optimization Sprint

A Keyva Cloud Cost Optimization Sprint is a pre-scoped, fixed-price engagement designed to identify, prioritize, and implement cloud cost savings across your environment, and delivered in a structured 6-week sprint with clear, measurable outcomes. What’s Included: Week 1–2 Discovery & Audit Week Full cloud environment audit across all accounts/subscriptions. Inventory of all compute, storage, network, and managed services. Cost breakdown by service, team, environment (dev/test/prod), and tag. Identification of unused, idle, and over-provisioned resources. Deliverable: Cloud Cost Audit Report with full resource inventory and cost attribution map. 3–4 Analysis & Roadmap Right-sizing analysis and recommendations for compute instances and databases. License optimization review (reserved instances, savings plans, committed use). Automation gap assessment for resource lifecycle management. Prioritized savings roadmap with impact matrix. Deliverable: Cost Optimization Roadmap with prioritized recommendations and projected savings by item. Week 5–6 Implementation Implementation of top-priority quick wins (examples): right-sizing of flagged resources, tagging enforcement, budget alerts and automated shutdown policies for dev/test environments, infrastructure-as-code updates for identified patterns. Deliverable: Implemented changes with before/after cost comparison report and runbook for ongoing governance. Case Study: A Keyva client running workloads across eight Azure subscriptions was spending approximately $180,000 per month on cloud infrastructure. Their leadership requested a cost review. Within six weeks, Keyva’s team used tagging strategies to break down cost allocations by environment, identified over-provisioned resources, implemented lifecycle automation, bundled licensing, and configured budget-based alarms. Result: $20,000 per month in sustained savings — an 11% reduction with a payback period under 2 months. Why Keyva [post_title] => Workshops & Assessments: Cost Optimization [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => cost-optimization [to_ping] => [pinged] => [post_modified] => 2026-06-01 15:43:30 [post_modified_gmt] => 2026-06-01 15:43:30 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5248 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [6] => WP_Post Object ( [ID] => 5246 [post_author] => 15 [post_date] => 2026-06-01 15:02:09 [post_date_gmt] => 2026-06-01 15:02:09 [post_content] => CI/CD pipelines are the foundation of modern software delivery, yet most evolve incrementally under delivery pressure without a structured review against best practices. Over time, this results in slow build times, fragile deployments, security gaps, and escalating infrastructure costs. Keyva’s Pipeline Assessment and Optimization solution delivers a structured, expert led evaluation of your CI/CD pipeline portfolio and produces a prioritized, actionable optimization roadmap in three weeks or less.

Assessment Approach

The engagement follows a proven three phase methodology: discovery, analysis, and executive readout. Keyva engineers work directly with your teams, reviewing repositories and pipeline configurations in place and benchmarking your current state against industry best practices across more than ten critical domains. Each engagement evaluates pipelines across the following capability areas: Version control practices, pull request and merge workflows, CI pipeline structure, CD and deployment processes, GitOps practices, pipeline security, testing strategy, pipeline quality, standardization, collaboration and ownership, infrastructure, performance, and observability.

Supported Platforms

The assessment supports a broad range of leading CI/CD platforms commonly used across modern development environments, ensuring relevance regardless of tooling choices. CI/CD Technologies: GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps Pipelines, Google Cloud Build, CircleCI, Bitbucket Pipelines, TeamCity, Harness, Argo CD, Flux CD, Tekton, and AWS CodePipeline.

Scope of Engagement

The engagement is delivered through a structured, phased approach designed to provide rapid insight, actionable recommendations, and clear alignment across engineering, platform, and security teams. Discovery and Inventory This phase establishes a clear, shared understanding of the current pipeline landscape and developer experience. Deliverable: Complete pipeline inventory, baseline metrics, and confirmed assessment scope.

Pipeline Analysis

This phase delivers a deep technical and operational evaluation of pipelines across all assessment domains. Deliverable: Comprehensive findings matrix and validated interview readouts with the platform team. Optimization and Roadmap Handover This phase translates findings into an executable plan aligned to business and engineering priorities. Deliverable: Assessment report, executive readout deck, and implementation roadmap.

Outcome

Keyva’s Pipeline Assessment and Optimization solution delivers measurable operational, security, and cost improvements across the software delivery lifecycle. [post_title] => Workshops & Assessments: Pipeline Assessment and Optimization [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => pipeline-assessment-and-optimization [to_ping] => [pinged] => [post_modified] => 2026-06-01 15:43:40 [post_modified_gmt] => 2026-06-01 15:43:40 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5246 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [7] => WP_Post Object ( [ID] => 5242 [post_author] => 15 [post_date] => 2026-06-01 14:42:30 [post_date_gmt] => 2026-06-01 14:42:30 [post_content] => The rapid reduction in TLS certificate lifetimes is fundamentally changing how organizations must manage certificate operations. As certificate validity shrinks toward a 47 day standard, what was once a simple annual renewal process now requires frequent, repeatable action across every endpoint. At scale, manual certificate management is no longer viable. Keyva’s CertOps Automation solution addresses this challenge through a fully automated, event driven approach to certificate lifecycle management. Built as an Ansible collection, CertOps orchestrates issuance, deployment, renewal, and validation across environments. Its Event Driven Ansible component continuously monitors certificate state and proactively triggers renewal workflows as thresholds are reached, ensuring security, compliance, and operational continuity without manual intervention.

Certificate Lifetime Reduction Timeline

TLS certificate lifetimes are shrinking rapidly, creating a material operational challenge for organizations relying on manual or semi manual renewal processes. What was once manageable is quickly becoming unsustainable at scale.

Scope of Engagement

The engagement is designed to move quickly from discovery to a production ready automation pipeline while minimizing risk and operational disruption. The scope focuses on practical deployment, validation, and knowledge transfer.

Discovery and Environment Setup

This phase establishes visibility, tooling, and a solid operational foundation for certificate automation.

Pilot Deployment and Handover

The pilot phase validates the full certificate lifecycle in a controlled environment and transitions operational ownership to your team. Deliverable: Production ready pipeline supporting one certificate authority and one platform, including runbooks and AWX job templates.

Business Outcome

The Keyva CertOps Automation solution delivers durable operational improvements, reducing risk while eliminating manual toil associated with certificate management at scale. [post_title] => Workshops & Assessments: CertOps Automation [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => certops-automation [to_ping] => [pinged] => [post_modified] => 2026-06-01 15:43:49 [post_modified_gmt] => 2026-06-01 15:43:49 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5242 [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] => 5268 [post_author] => 7 [post_date] => 2026-06-30 14:09:24 [post_date_gmt] => 2026-06-30 14:09:24 [post_content] => Perhaps you're testing across multiple machines and don't want to push incomplete code. Maybe you're working with a collegue on a particularly long flight. Or perhaps your main repository has become unreachable, and you don't know when it will be back. At its core, Git is designed to not require a central service or authority to work. This might come as something of a surprise, since most projects use a central authority such as GitHub, GitLab or BitBucket. However, within your pulled repository exists a complete history of your pulled branch's changes, from the very first commit. Because of this, any machine can act as a Git server. This can be leveraged even with the general internet unavailable; no special services or daemons are required. Not even a reliable network connection is required, so long as your have a USB drive handy. All that you need between two computers is both having git, and both able to communicate in some way. ## Option 1 - Bare repo on shared media Those of us who collaborated with others in a pre-internet world know the usefulness of sneakernet. For the rest who are unaware, this is basically comprised of adding your data to media storage (these days, probably a USB drive) and phyiscally walking it over to where it needs to be. This is perhaps the simplest way to get around a downed service issue [xxx - revisit, don't like wording]. To do this, first we initialize a bare repo on our media: ``` cd /media/usb git init --bare repo.git ``` Then, we can add this path as a remote to push to ``` cd ~/src/repo git remote add usb-stick /media/usb/repo.git git push usb-stick main ``` Finally, we unmount the USB and bring it to the target machine and run the same setup before pulling: ``` cd ~/src/repo git remote add usb-stick /media/usb/repo.git git pull usb-stick main ``` Now, in order to sync later, the chosen media can be passed back and forth as your temporary central repository. If you only need to pass a repository and not later share history, an even simpler cludgel is available. With the above example, `/media/usb/repo.git` is effectively a copy of `~/src/repo/.git`. It would also be possible to simply: ``` cp -r ~/src/repo/.git /media/usb/repo.git ``` Then, on the target machine: ``` mkdir ~/src/repo ~/src/repo/ cp -r /media/usb/repo.git ~/src/repo/.git git reset --hard ``` At this point, you have a carbon copy of the history and a working source directory. Actually a bit better than the prior solution for initial sharing, because this method would share all branches on the source machine as well, instead of needing to individually push the same branches. ## Option 2 - Direct peer-to-peer over local IP It's also possible with a bridge, hotspot, or even just direct connection to do this over a two terminal network. In this example, we will assume that the source computer has an IP of 192.168.1.10 on this network. It's important to preface this by adding: don't do this outside of an isolated network as this makes your served repo readable to anyone on your network. It's the sort of solution meant for long car rides and international flights, not general use. On our source machine: ``` # Make our service path mkdir -p /srv/git && cd /srv/git # Init a bare repo git init --bare repo.git # Add this local repo to your remotes; like the USB method, we can simply use the path cd ~/src/repo git remote add local /srv/git/repo.git git push local main # Return to the service path and launch the git daemon cd /srv/git git daemon --base-path=. --export-all --reuseaddr --verbose --port=9418 ``` This invokes a lightweight, read-only service daemon that is built into git, running on git's default port of 9418. It requires no authentication, which is fine for our very small, isolated network. Then, our target can clone directly from this repository: ``` cd ~/src git clone git://192.168.1.10/repo.git ``` Best practices would have both machines running their own daemon, commiting and pushing to their local path and each machine pulling from each other. If it's more desirable however, one can also have our source machine act as a central authority. Again, not to be used outside an isolated network, and with additional peril, taht this method would allow not only readability to everything on the network, but writability as well. ``` # Before running `git daemon`: cd /srv/git/repo.git git config receive.denyCurrentBranch ignore # `warn` is also an option in place of `ignore` cd /srv/git # Note the addition of --enable=receive-pack git daemon --base-path=. --export-all --reuseaddr --verbose --port=9418 --enable=receive-pack ``` ## Option 3 - With SSH transport (most realistic for an office or VPN setting) If `sshd` is available, changes can be pushed directly using SSH without running any daemon. Note for MacOS: enable Remote Login in Sytem Settings -> General -> Sharing -> Advanced -> Remote Login For Linux: `systemctl start sshd` (assuming the sshd package is available) For Windows: You will require WSL, then installing the relevant package (most distros use the package `openssh-server`) and then port forwarding. This is beyond the scope of this guide, but it should be searchable, knowing what to look for. This will also likely require permissions handling, also beyond the scope of this guide. For Linux, search for how to add users and ssh public keys and group permissions with `chmod` or `setfacl`. As before, we will set up a directory for our repo and push to it normally: ``` # Make our service path mkdir -p /srv/git && cd /srv/git # Init a bare repo git init --bare repo.git # Add this local repo to your remotes; like the USB method, we can simply use the path cd ~/src/repo git remote add local /srv/git/repo.git git push local main ``` Then, for our target machine, we can clone directly as if a path over SSH: ``` git remote add machine1 ssh://user@192.168.1.10/srv/git/repo.git git pull machine1 main ``` If you wish to learn about more retro way of creating patch files (the method of choice for collaboration over email), I suggest looking into the offical documention for these methods https://git-scm.com/docs/git-bundle, https://git-scm.com/docs/git-send-email and https://git-scm.com/docs/git-format-patch. [table id=11 /] [post_title] => # Gitting Good - How to Colabborate Without a Central Service [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => gitting-good-how-to-colabborate-without-a-central-service [to_ping] => [pinged] => [post_modified] => 2026-06-30 14:09:24 [post_modified_gmt] => 2026-06-30 14:09:24 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5268 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 161 [max_num_pages] => 21 [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] => )

# Gitting Good – How to Colabborate Without a Central Service

Perhaps you’re testing across multiple machines and don’t want to push incomplete code. Maybe you’re working with a collegue on a particularly long flight. Or perhaps your main repository has ...

When AI Actually Works in IT Operations — And Why Most Teams Are Doing It Wrong

There’s a version of AI adoption in IT ops that looks something like this: someone buys a Copilot license, attaches it to ServiceNow, and waits for the magic to happen. ...

Keyva BMC Atrium Data Pump Certified for Zurich Release

Keyva is pleased to announce the certification of the Keyva BMC Atrium Data Pump v2.0.1 for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from ...

Keyva HP Universal CMDB Data Pump Certified for Zurich Release

Keyva is pleased to announce the certification of the Keyva HP Universal CMDB Data Pump for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from ...

Keyva BMC Atrium Data Pump Certified for Zurich Release

Keyva is pleased to announce the certification of the Keyva BMC Atrium Data Pump v3.2.1 for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from ...

Workshops & Assessments: Cost Optimization

Cloud environments grow fast, and so do bills. Without deliberate optimization, organizations routinely overspend by 20–40% on infrastructure that sits idle, is over-provisioned, or lacks lifecycle automation. The complexity of ...

Workshops & Assessments: Pipeline Assessment and Optimization

CI/CD pipelines are the foundation of modern software delivery, yet most evolve incrementally under delivery pressure without a structured review against best practices. Over time, this results in slow build ...

Workshops & Assessments: CertOps Automation

The rapid reduction in TLS certificate lifetimes is fundamentally changing how organizations must manage certificate operations. As certificate validity shrinks toward a 47 day standard, what was once a simple ...