{"id":37607389,"url":"https://github.com/flyingcircusio/aramaki","last_synced_at":"2026-01-16T10:13:32.603Z","repository":{"id":57411266,"uuid":"456936217","full_name":"flyingcircusio/aramaki","owner":"flyingcircusio","description":"Aramaki - a federated DevOps control plane","archived":false,"fork":false,"pushed_at":"2024-03-18T09:05:59.000Z","size":463,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-09-22T10:23:49.038Z","etag":null,"topics":["automation","devops","federation","monitoring"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/flyingcircusio.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2022-02-08T13:06:36.000Z","updated_at":"2024-10-31T13:45:02.000Z","dependencies_parsed_at":"2024-02-01T18:25:52.218Z","dependency_job_id":"f7928980-1c80-4eb6-b441-cee929c16c4b","html_url":"https://github.com/flyingcircusio/aramaki","commit_stats":{"total_commits":7,"total_committers":2,"mean_commits":3.5,"dds":0.1428571428571429,"last_synced_commit":"dc24219a8f9636bf38d27f07f6f7f27aa0f3c72f"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/flyingcircusio/aramaki","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/flyingcircusio%2Faramaki","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/flyingcircusio%2Faramaki/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/flyingcircusio%2Faramaki/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/flyingcircusio%2Faramaki/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/flyingcircusio","download_url":"https://codeload.github.com/flyingcircusio/aramaki/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/flyingcircusio%2Faramaki/sbom","scorecard":{"id":405097,"data":{"date":"2025-08-11","repo":{"name":"github.com/flyingcircusio/aramaki","commit":"499126a1db34d6a2102fdb702f9df496dc60808b"},"scorecard":{"version":"v5.2.1-40-gf6ed084d","commit":"f6ed084d17c9236477efd66e5b258b9d4cc7b389"},"score":2.5,"checks":[{"name":"Packaging","score":-1,"reason":"packaging workflow not detected","details":["Warn: no GitHub/GitLab publishing workflow detected."],"documentation":{"short":"Determines if the project is published as a package that others can easily download, install, easily update, and uninstall.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#packaging"}},{"name":"Code-Review","score":0,"reason":"Found 0/30 approved changesets -- score normalized to 0","details":null,"documentation":{"short":"Determines if the project requires human code review before pull requests (aka merge requests) are merged.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#code-review"}},{"name":"Dangerous-Workflow","score":10,"reason":"no dangerous workflow patterns detected","details":null,"documentation":{"short":"Determines if the project's GitHub Action workflows avoid dangerous patterns.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#dangerous-workflow"}},{"name":"Maintained","score":0,"reason":"0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0","details":null,"documentation":{"short":"Determines if the project is \"actively maintained\".","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#maintained"}},{"name":"Token-Permissions","score":0,"reason":"detected GitHub workflow tokens with excessive permissions","details":["Warn: no topLevel permission defined: .github/workflows/test.yml:1","Info: no jobLevel write permissions found"],"documentation":{"short":"Determines if the project's workflows follow the principle of least privilege.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#token-permissions"}},{"name":"CII-Best-Practices","score":0,"reason":"no effort to earn an OpenSSF best practices badge detected","details":null,"documentation":{"short":"Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#cii-best-practices"}},{"name":"SAST","score":0,"reason":"no SAST tool detected","details":["Warn: no pull requests merged into dev branch"],"documentation":{"short":"Determines if the project uses static code analysis.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#sast"}},{"name":"Binary-Artifacts","score":10,"reason":"no binaries found in the repo","details":null,"documentation":{"short":"Determines if the project has generated executable (binary) artifacts in the source repository.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#binary-artifacts"}},{"name":"Pinned-Dependencies","score":0,"reason":"dependency not pinned by hash detected -- score normalized to 0","details":["Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/test.yml:15: update your workflow using https://app.stepsecurity.io/secureworkflow/flyingcircusio/aramaki/test.yml/main?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/test.yml:16: update your workflow using https://app.stepsecurity.io/secureworkflow/flyingcircusio/aramaki/test.yml/main?enable=pin","Warn: third-party GitHubAction not pinned by hash: .github/workflows/test.yml:17: update your workflow using https://app.stepsecurity.io/secureworkflow/flyingcircusio/aramaki/test.yml/main?enable=pin","Info:   0 out of   1 GitHub-owned GitHubAction dependencies pinned","Info:   0 out of   2 third-party GitHubAction dependencies pinned"],"documentation":{"short":"Determines if the project has declared and pinned the dependencies of its build process.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#pinned-dependencies"}},{"name":"Security-Policy","score":0,"reason":"security policy file not detected","details":["Warn: no security policy file detected","Warn: no security file to analyze","Warn: no security file to analyze","Warn: no security file to analyze"],"documentation":{"short":"Determines if the project has published a security policy.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#security-policy"}},{"name":"Fuzzing","score":0,"reason":"project is not fuzzed","details":["Warn: no fuzzer integrations found"],"documentation":{"short":"Determines if the project uses fuzzing.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#fuzzing"}},{"name":"License","score":9,"reason":"license file detected","details":["Info: project has a license file: LICENSE:0","Warn: project license file does not contain an FSF or OSI license."],"documentation":{"short":"Determines if the project has defined a license.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#license"}},{"name":"Signed-Releases","score":-1,"reason":"no releases found","details":null,"documentation":{"short":"Determines if the project cryptographically signs release artifacts.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#signed-releases"}},{"name":"Branch-Protection","score":0,"reason":"branch protection not enabled on development/release branches","details":["Warn: branch protection not enabled for branch 'main'"],"documentation":{"short":"Determines if the default and release branches are protected with GitHub's branch protection settings.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#branch-protection"}},{"name":"Vulnerabilities","score":0,"reason":"13 existing vulnerabilities detected","details":["Warn: Project is vulnerable to: PYSEC-2024-230 / GHSA-248v-346w-9cwc","Warn: Project is vulnerable to: PYSEC-2024-60 / GHSA-jjg7-2v4v-x38h","Warn: Project is vulnerable to: GHSA-9hjg-9r4m-mvj7","Warn: Project is vulnerable to: GHSA-9wx4-h78v-vm56","Warn: Project is vulnerable to: PYSEC-2025-49 / GHSA-5rjg-fvgr-3xxf","Warn: Project is vulnerable to: GHSA-cx63-2mw6-8hw5","Warn: Project is vulnerable to: GHSA-34jh-p97f-mpxf","Warn: Project is vulnerable to: GHSA-48p4-8xcf-vxj5","Warn: Project is vulnerable to: GHSA-pq67-6m6q-mj2v","Warn: Project is vulnerable to: PYSEC-2024-211 / GHSA-3f84-rpwh-47g6","Warn: Project is vulnerable to: PYSEC-2024-210 / GHSA-9298-4cf8-g4wj","Warn: Project is vulnerable to: PYSEC-2024-188 / GHSA-mg3v-6m49-jhp3","Warn: Project is vulnerable to: PYSEC-2023-121"],"documentation":{"short":"Determines if the project has open, known unfixed vulnerabilities.","url":"https://github.com/ossf/scorecard/blob/f6ed084d17c9236477efd66e5b258b9d4cc7b389/docs/checks.md#vulnerabilities"}}]},"last_synced_at":"2025-08-18T20:59:58.779Z","repository_id":57411266,"created_at":"2025-08-18T20:59:58.780Z","updated_at":"2025-08-18T20:59:58.780Z"},"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28478049,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-16T06:30:42.265Z","status":"ssl_error","status_checked_at":"2026-01-16T06:30:16.248Z","response_time":107,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["automation","devops","federation","monitoring"],"created_at":"2026-01-16T10:13:32.497Z","updated_at":"2026-01-16T10:13:32.584Z","avatar_url":"https://github.com/flyingcircusio.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Aramaki - a federated DevOps control plane\n\n\u003e \"Aramaki never engages in direct missions, but offers a great array of\n   diplomatic support in return.\"\n\u003e\n\u003e [Ghost in the Shell Wiki](https://ghostintheshell.fandom.com/wiki/Daisuke_Aramaki)\n\n## Vision\n\n* Watching your application as it works in its environment\n* providing a helpful user interface to put events into context\n  and help make sense out of the time line\n* allowing a multi-disciplinary team to operate the application and its\n  environment and move it to more desirable states\n\n## Problems we want to solve\n\n### It's 3am – someone needs to flush the Varnish cache again\n\nIt's 3am and I haven't touched this system/project for a long time. How did that\nwork in *this* project and did someone just do that already?\n\nSometimes we need to get people into projects quickly. They need to orient\nthemselves on a technical and social level:\n\n* What are the rules for things we can touch or we should escalate to someone\n  else (internally or externally)?\n\n* Where are the dashboards? Which are relevant?\n\n* Is this thing always broken or did that just happen?\n\n* What has been going on today and in the last days?\n\n\n### Support workflows from multiple, overlapping perspectives\n\nFor example in monitoring: infrastructure teams want performing reviews of thousands of alerts across dozens of projects, application operations teams reviewing other aspects of the same projects, a customer or developer reviewing the monitoring situation of a single project.\n\n### Shall we use my Jira, your Gitlab or her YouTrack?\n\nAllow fine grained customization without having to have a single centralised\ninstance that requires over-modelling the world and then creating contradicting\nsituations when handled in multi-tenant scenarios. This is what we think\nfederation will solve. Also, this should create smaller customer/project\nspecific systems that are easier to understand and compose.\n\n### Reduce the amount of third party tools\n\nEspecially to avoid ending up with an ever-changing cacophony of questionable\nlicense/business strategies that are built for bait-and-switch around selling a product instead of delivering a service.\n\nIn our case, we currently want to get rid of Sensu and Consul, as well as\noutside monitoring tools.\n\n### Improve communication between project owners, developers, and ops\n\nThis is a social problem we want to provide good assistance for. \n\nOne interesting aspect here is that we want to provide regular reviews. We want\nto avoid writing reports that aren't read.\n\n\n## Things we want to avoid\n\nWe are dangerously close to second-system-syndrome as well as not-invented-here.\nNevertheless, we thought about this deeply and will integrate with existing\nsystems where it makes sense, but will implement light-weight solutions reduce\nintegration complexity where reasonable. Especially we do not want to create a\nsystem that simply is a cacophony of random third party services just cobbled\ntogether.\n\nThis is not intended to become a \"NoOps\" product that solves all social problems. This is intended to implement a form of \"cogntive augmentation\" for people to cooperate. \n\nThis is about balancing technical and social interactions and providing a way to\nintegrate them.\n\nThis should also not become a closed platform solution. We think that – as a\nprofessional community – we need to get better with new FLOSS projects to find\nand support business models that stay open and don't perform switch-and-bait.\n\n\n## The minimal *viable* product\n\nThe minimal viable product will be a mixture between showing the proper foundational technologie with a federated approach and adding a variety of \nspecific use cases to get a sense of the landscape and what is needed in\nactual situations.\n\nSo the major milestones will be:\n\n* a server that can federate with other servers (using websockets)\n* an agent that can be asked to perform actions and send observations to its server\n* a data model around projects (to be renamed!) that can be interacted with from multiple servers\n* have a proper security model for agents, servers and especially around\n  federation.\n\nSpecific use cases in the beginning:\n\n* monitoring and review (to replace Sensu and Uchiwa)\n* alerting\n* inventory management\n* ticket system integration\n\n\n# Foundational thoughts\n\n* We want to avoid another platformization approach. We think that – as a\n  professional community of developers an operators – we need to get better\n  with new FOSS projects to find and support sustainable business models.\n\n* Provide a common technical vocabulary to pull data from many different sources\n  into a common, distributed environment. We imagine this data to include\n  application events, tickets/issues, information about code and more.\n\n* Consider operating an application to be an effort in the complex domain: it's\n  important to discover previously unknown relationships and cooperating from\n  multiple perspectives. This is to a large part a social issue that needs to\n  be tackled and supported by proper technical solutions(cognitive augmentation\n  vs. replacement).\n\n* We consider a mixed audience that includes managers, developers, operators\n  where in specific situations the competencies may not be clearly laid out\n  along team or people boundaries but are intermingled in interesting ways.\n\n* Create multiple smaller systems that can be customized and adapted easily vs.\n  one centralized system.\n\n* We might want to customize operations on a \"per system\" level and intend to do\n  that by providing configuration and code for every system through a\n  (Git) repository that tracks the history of the project's config (and could\n  thus be re-integrated into the system's timeline itself).\n\n  This customization could allow to distribute certain policy decisions\n  (which has been a foundational aspect of designing systems for a long time)\n  and providing an overall system that has \"building block\" characteristics.\n\n  Instead of creating an overly complicated module in our centralized system on\n  how to schedule maintenances, we could simply defer this to the customer's\n  instance and he can choose to use one of the pre-made policies (which can be\n  simplified from the current approach by providing multiple simple versions)\n  or roll his own. This would not complicate our centralized code base which\n  could quickly become too complicated (even when trying to make those things more\n  pluggable and use a local \"strategy\" pattern we would still need to make changes\n  to a centralized system which may not be possible in a timely manner and thus\n  becoming an unnecessary contention point for users).\n\n* A distributed system would also allow different customers to run different\n  versions of the same plugin instead of running into the NxM problem. If a\n  customer needs an old version of a ticket system plugin then it's fine if he\n  runs that in his instance and others run newer versions on their instances.\n\n* On top of the federated instance model we provide agents that that can perform\n  specific tasks within a system. Agents might be interacting with messages\n  from federated instances as well.\n\n* We imagine an open, federated network that allows to assemble systems by using\n  other systems in interesting ways, but also have sufficient capabilities to\n  manage and recognize (temporary) trust between actors in a highly secure\n  fashion.\n\n* Take inspiration from the ActivityPub/Fediverse approach without implementing\n  it as a core technology. See the `REJECTED-IDEAS.md` for details.\n\n* Take inspiration from Domain Driven Design without following their\n  implementation ideas 1:1. Also see `REJECTED-IDEAS.md` for details.\n\n* batou showed us that a fractal design (using self-similar structures) can be\n  very powerful. The current design considers \"Systems\" to be a good starting\n  point to answer the question \"What is the /thing/ we managing here?\". Systems\n  can have subsystems and can be aggregated. We might want to also use the\n  word \"Component\" somewhere to indicate a leaf where it doesn't get more\n  granular.\n\n  (Sub-)Systems can be \"remote\" or internal and thus federation comes into play.\n\n  I imagine subsystems could be \"The Flying Circus Infrastructure\" which in turn\n  may be split up into data centers and subsystems therein\n  (\"storage\" and \"compute\").\n\n  This would help automatically routing certain information (there's a problem\n  with this storage, but you only get to see messages about that fact if you\n  use the actual affected systems.)\n\n  We could also use multiple aggregate systems like: all subsystems from this\n  data center versus all subsystems that are storage systems in all data\n  centers. \"Simple\" aggregates might be useful to not require individual\n  repositories to manage them but could be defined in one repository that\n  ends up \"generating\" multiple aggregates dynamically.\n\n  An interesting detail is whether those \"anemic\" aggregates may generate their\n  own data in case that users might be subscribed to the smallest systems\n  (\"storage in this data center\") and thus could miss notifications from the\n  aggregates that might be relevant to them but do not fit the granularity of\n  either subsystem.\n\n  I decided to go with \"System\" after reading\n  http://sysarch.pbworks.com/w/page/7241231/FrontPage#EverySystemConsistsofSubsystems\n  again.\n\n* Systems are aggregated top down, not bottom up: a subsystem doesn't have a parent,\n  but systems can aggregated other systems - which in turn means a system can be a \n  subsystem for multiple higher level systems.\n\n  This relationship is intended to make larger, complex systems more manageable.\n  Inversely, aggregating a subsystem into a larger system may not cause the\n  actual thing the subsystem represent to break! (E.g. adding an environment to\n  a project must not - in the general case - cause the application to stop\n  working because of e.g. IP addresses changing)\n\n* We also need to be aware to not scale by aggregration, but support scaling by\n  decomposition and recombination.\n\n  For example: instead of creating higher order status pages by simply using the\n  summary status from a subordinate status page, we should(recursively) provide\n  access to both the summary status as well as any intermediate layer data.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fflyingcircusio%2Faramaki","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fflyingcircusio%2Faramaki","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fflyingcircusio%2Faramaki/lists"}