[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-71883":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":21,"hasPages":21,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":27,"discoverSource":28},71883,"spec","score-spec\u002Fspec","score-spec","The Score Specification provides a developer-centric and platform-agnostic Workload specification to improve developer productivity and experience. It eliminates configuration inconsistencies between environments.","https:\u002F\u002Fscore.dev\u002F",null,"Makefile",8047,2147,226,6,0,2,12,41,"Apache License 2.0",false,"main",[],"2026-06-12 02:02:55","[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-Apache_2.0-blue.svg)](https:\u002F\u002Fopensource.org\u002Flicenses\u002FApache-2.0)\n[![Contributor Covenant](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FContributor%20Covenant-2.1-4baaaa.svg)](CODE_OF_CONDUCT.md)\n[![good first issues](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fissues-search\u002Fscore-spec\u002Fspec?query=type%3Aissue%20is%3Aopen%20label%3A%22good%20first%20issue%22&label=good%20first%20issues&style=flat&logo=github)](https:\u002F\u002Fgithub.com\u002Fscore-spec\u002Fspec\u002Fissues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)\n\n![Score banner](docs\u002Fimages\u002Fbanner.png)\n\n## ![Score](docs\u002Fimages\u002Flogo.svg) The Score Specification\n\nScore is an open-source workload specification designed to simplify development for cloud-native developers. The specification enables you to describe your workload's configuration in a vendor-neutral way, eliminating the need for tooling-specific syntax from platforms such as Docker Compose or Kubernetes. By leveraging familiar concepts and semantics, defining a workload’s configuration becomes as simple as stating, “I want a database of type X and an event queue of type Y to accompany my workload”.\n\nBelow is an example of a Score specification describing a web server that queries a Postgres database on each request. Typically, this file is saved alongside the workload's source code in version control.\n\n```YAML\n# The version string helps identify the Score file syntax\napiVersion: score.dev\u002Fv1b1\nmetadata:\n  name: sample\n\n# A set of containers deployed together for this Workload.\ncontainers:\n  main:\n    # The \"default\" image for our service. When deploying, we may override this with a particular tag.\n    image: ghcr.io\u002Fscore-spec\u002Fsample-app-gif:sha-2533037\n    variables:\n      # Pass the resource outputs to our container as environment variables. The Score implementation takes care of securing any secret access as needed.\n      PG_CONNECTION_STRING: \"postgresql:\u002F\u002F${resources.db.username}:${resources.db.password}@${resources.db.host}:${resources.db.port}\u002F${resources.db.database}?sslmode=disable\"\n\n# The service ports indicate which ports of the Workload are exposed for other services to call.\nservice:\n  ports:\n    web:\n      port: 8080\n\n# Each resource dependency has a name and definition that helps the Score implementation link or provision the required resource.\nresources:\n  db:\n    # This database is specific to this Workload and not shared.\n    type: postgres\n  dns:\n    # Ensure a dns name is available for request routing.\n    type: dns\n  route:\n    # We want to ensure that requests on the Workload hostname go to our service port.\n    type: route\n    params:\n      host: ${resources.dns.host}\n      path: \u002F\n      port: 8080\n```\n\n### Key Features of Score\n\nLooking at the example above, you'll notice that the Score specification is:\n\n* **platform-agnostic**: Score is not tied to any specific platform or tool. It integrates seamlessly with Docker, Kubernetes, Helm, and other container orchestration platforms, allowing developers to define the Score spec once, independently of the target environments.\n\n* **environment-agnostic**: Score captures the configuration that remains consistent across all environments, effectively separating environment-agnostic from environment-specific configurations. For instance, the database connection string `PG_CONNECTION_STRING` in the example above is parameterized (i.e. described in an environment-agnostic way), allowing it to be resolved in each target environment with the appropriate credentials.\n\n* **tightly scoped**: Score describes workload-level properties. It does not intend to be a fully featured YAML replacement for any platform, thereby shielding developers from the complexity of container orchestration tools like Kubernetes.\n\n* **declarative**: With Score, developers declare what their workload requires to run as part of the Score specification. The platform in the target environment is responsible for resolving individual runtime requirements. This establishes a contract between dev and ops: If the requirements listed in the spec are honoured, the workload will run as intended.\n\nThe current version of the specification schema is stored [here](.\u002Fscore-v1b1.json). For a more detailed specification reference, check out our [developer documentation](https:\u002F\u002Fdocs.score.dev\u002Fdocs\u002Fscore-specification\u002Fscore-spec-reference\u002F).\n\n## ![Score](docs\u002Fimages\u002Flogo.svg) Implementation of the Score Specification\n\nOnce you define your workload's runtime requirements with the Score specification, a Score Implementation translates it into the desired target output format as illustrated in the graphic below.\n\n![how-score-works](docs\u002Fimages\u002Fhow-score-works.png)\n\nCurrently, we offer two reference implementations:\n\n* [score-compose](https:\u002F\u002Fgithub.com\u002Fscore-spec\u002Fscore-compose): Converts your Score specification into a `docker-compose.yaml` file.\n* [score-k8s](https:\u002F\u002Fgithub.com\u002Fscore-spec\u002Fscore-k8s): Generates `manifests.yaml` files from your Score specification to deploy to a Kubernetes cluster.\n\nThese implementations are suitable for practical use and serve as blueprints for creating custom implementations. If you're interested in building a Score implementation but need guidance, feel free to reach out — we're here to help!\n\nCommunity-built implementations are typically hosted and maintained by their creators. These can be referenced in our documentation or kept private. If a contributor wishes to donate their implementation to our project, we are open to exploring that option.\n\n## ![Score](docs\u002Fimages\u002Flogo.svg) Benefits of Score\n\nScore aims to reduce developer toil and cognitive load by only having to define a single specification file that works across multiple platforms. Cloud native developers often struggle with configuration inconsistencies between environments. This gets even more complicated when the technology stack in each environment is different. For example: What if you use Docker Compose for local development, but deploy to a Kubernetes-based development environment? Not only do you have to figure out Docker Compose and Kubernetes, but you need to keep them in sync. This results in various bottlenecks along the application delivery lifecycle:\n\n- Tech & tools that require specialized knowledge and operational expertise are imposed on developers.\n\n- Different configuration rules, constructs and values between local and remote environments increase the risk of configuration inconsistencies.\n\n- Keeping a multitude of platforms and environment-specific configuration files in sync leads to repetitive configuration work.\n\nScore provides a single, easy to understand specification for each workload that describes its runtime requirements in a declarative manner. The `score.yaml` file allows generating configuration in an automated, standardized and one directional way.\n\nBy reducing the risk of incorrect or inconsistent configurations across environments, Score helps developers focus on their core tasks and enhances their day-to-day work experience.\n\n## ![Get in touch](docs\u002Fimages\u002Fget-involved.svg) Get in touch\n\nConnect with us through the [Score](https:\u002F\u002Fcloud-native.slack.com\u002Farchives\u002FC07DN0D1UCW) channel in the CNCF Slack (\u003Chttps:\u002F\u002Fslack.cncf.io\u002F>) or contact us via email at team@score.dev.\n\nWe host regular community meetings to discuss updates, share ideas, and collaborate. Here are the details:\n\n| Community call | Info |\n|:-----------|:------------|\n| Meeting Link | Join via [Zoom](https:\u002F\u002Fzoom-lfx.platform.linuxfoundation.org\u002Fmeeting\u002F98284206225?password=a09e77df-8c63-44ca-8a48-12de22fdffe4) or view the [Calendar](https:\u002F\u002Fzoom-lfx.platform.linuxfoundation.org\u002Fmeetings\u002Fscore?view=month) |\n| Meeting Agenda & Notes | Add to our agenda or review minutes [here](https:\u002F\u002Fgithub.com\u002Fscore-spec\u002Fspec\u002Fdiscussions\u002Fcategories\u002Fcommunity-meetings) |\n| Meeting Time | 3:00-4:00 CET\u002FCEST, every first Thursday of the month unless specified |\n\nIf you can't attend at the scheduled time but would like to discuss something, please reach out. We’re happy to arrange an ad-hoc meeting that fits your schedule.\n\n### Documentation\n\nYou can find our documentation at [docs.score.dev](https:\u002F\u002Fdocs.score.dev\u002Fdocs\u002F).\n\n### Roadmap\n\nSee [Roadmap](roadmap.md). You can [submit an idea](https:\u002F\u002Fgithub.com\u002Fscore-spec\u002Fspec\u002Fissues\u002Fnew) anytime.\n\n### Contribution Guidelines and Governance\n\nOur general contributor guidelines can be found in [CONTRIBUTING.md](CONTRIBUTING.md). Please note that some repositories may have additional guidelines. For more information on our governance model, please refer to [GOVERNANCE.md](GOVERNANCE.md).\n","Score 是一个开源的工作负载规范，旨在通过提供一种与平台无关的配置描述方式来简化云原生应用的开发流程，从而提高开发者效率并减少环境间配置不一致的问题。其核心功能包括支持以厂商中立的方式定义工作负载配置，无需依赖特定工具（如Docker Compose或Kubernetes）特有的语法；采用直观易懂的概念和语义使得服务配置更加简单直接。此外，Score 能够无缝集成多种容器编排平台。该项目特别适用于希望跨不同云环境或本地环境保持一致性的开发团队，以及寻求简化云原生应用程序部署过程的场景。","2026-06-11 03:39:18","high_star"]