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.
- 30%+ average cloud waste in enterprise environments
- 60% average cloud waste in enterprise environments
- $20K monthly average savings Keyva delivers per engagement
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.
- Cloud Cost Audit Report: Full inventory, cost attribution, and waste identification across all cloud accounts.
- Cost Optimization Roadmap: Prioritized recommendations ranked by projected savings and implementation effort.
- Implemented Quick Wins: Hands-on changes including right-sizing, lifecycle automation, and budget alerting.
- Before/After Savings Report: Quantified cost reduction with month-over-month comparison.
- Governance Runbook: Documented processes and IaC templates for ongoing cost discipline.
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
- Cloud-Native Expertise: Proven, hands-on experience across AWS, Azure, and Google Cloud, grounded in infrastructure-as-code and FinOps methodologies.
- Pre-Scoped for Predictability: Defined scope and transparent pricing ensure predictable outcomes with no scope creep or billing surprises.
- Execution-First Approach: Keyva delivers implemented solutions, not just recommendations. Measurable savings begin during the engagement
[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.
- Stakeholder alignment with engineering, platform, and security leads
- Comprehensive inventory of repositories and pipelines across all platforms
- Developer experience survey to identify friction points and bottlenecks
- Toolchain and integration mapping, including CAs, secrets, artifact registries, and SIEM
- Baseline metric collection covering build duration, failure rates, MTTR, and cost per build
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.
- Detailed review of all assessment categories for each CI/CD platform
- Security focused analysis including secrets handling, OIDC usage, software supply chain risks, and dependency scanning
- GitOps and infrastructure as code pipeline review covering Terraform, Ansible, and Helm
- Standardization gap analysis across teams and repositories
- Up to four structured interviews with platform teams to validate findings
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.
- Effort and impact based prioritization of all recommendations
- Phased implementation roadmap highlighting quick wins and strategic improvements
- Executive summary and readout presentation
- Full written assessment report
- Optional two week follow up check in to support execution momentum
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.
- Faster Software Delivery: Reduce average build times by 30–50 percent through caching, parallelization, and stage optimization, increasing deployment velocity
- Reduced Security Risk: Eliminate credential exposure, secret sprawl, and supply chain vulnerabilities before they become incidents or audit failures
- Recovered Engineering Capacity: Free developers from pipeline instability, manual fixes, and on call interruptions, redirecting time toward feature and platform work
- Audit Ready CI/CD Controls: Establish documented, enforceable standards that support compliance and governance requirements
- Lower Infrastructure Costs: Right size CI/CD compute resources and eliminate redundant or uncached build steps
- A Scalable Pipeline Foundation: Replace bespoke, fragile scripts with reusable templates and standards that scale without accruing technical debt
[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.
- EDA Monitor: Continuously monitors endpoints, certificate files, and Kubernetes secrets, triggering events when certificates approach renewal thresholds.
- Generate CSR: Generates private keys (RSA, ECDSA, or Ed25519) and certificate signing requests with full SAN and x509 extension support.
- Request Certificate: Submits CSRs to the certificate authority via API and automatically completes HTTP‑01, DNS‑01, and TLS‑ALPN‑01 challenges.
- Deploy Certificate: Pushes signed certificates, private keys, and chains across all configured target platforms.
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.
- Inventory existing certificates and certificate authority relationships
- Document target platforms and deployment topology
- Install and configure Ansible AWX, or integrate with an existing Ansible environment
- Configure CertOps for the applicable certificate authority, whether ACME‑based or commercial
- Establish a local development and testing environment using a self‑signed certificate authority
- Deliverable: A successful local test execution and a comprehensive inventory report of all existing certificates.
Pilot Deployment and Handover
The pilot phase validates the full certificate lifecycle in a controlled environment and transitions operational ownership to your team.
- Deploy CertOps to five pilot endpoints in a non production environment
- Execute the full lifecycle from CSR generation through deployment and validation
- Configure Event Driven Ansible for certificate expiration monitoring
- Conduct team walkthroughs and deliver operational runbook documentation Perform one guided non production deployment with customer team participation
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.
- A clear path to zero certificate related outages through process and architecture, not one off fixes
- More than 1,200 engineer hours per year redirected from maintenance tasks to platform and product work
- Improved audit readiness with on demand certificate evidence, reducing preparation time and audit findings
- Consistent key rotation on every renewal cycle with private keys never leaving their origin systems
- Reduced security exposure windows, shrinking from months to days
- Positive return on investment within two months for non production environments
- No per certificate licensing costs, allowing expenses to scale flat as certificate volume grows
- A one time investment that protects against all future certificate lifetime reductions
[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] =>
)