[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eThis page offers guidelines for naming conventions of Cloud projects related to API management, beyond just the production backend project.\u003c/p\u003e\n"],["\u003cp\u003eConsider creating different Cloud projects for development, staging, and alpha testing environments to isolate and manage API versions.\u003c/p\u003e\n"],["\u003cp\u003eVersioning APIs by including version numbers in the path (e.g., \u003ccode\u003e/v1/\u003c/code\u003e, \u003ccode\u003e/v2alpha/\u003c/code\u003e) is recommended to facilitate backward-incompatible changes.\u003c/p\u003e\n"],["\u003cp\u003eRunning private alpha tests of APIs is suggested to use a separate Cloud project for enhanced isolation, or alternatively, a distinct service within the same project with restricted access.\u003c/p\u003e\n"],["\u003cp\u003eOpen alpha tests can be done within the existing service and project, by simply altering the API path to indicate the alpha version.\u003c/p\u003e\n"]]],[],null,["# Planning Your Cloud Projects\n\nOpenAPI \\| [gRPC](/endpoints/docs/grpc/planning-cloud-projects \"View this page for the Cloud Endpoints gRPC docs\")\n\n\u003cbr /\u003e\n\nThis page provides recommendations for naming conventions of the Cloud projects\nthat you may need to create in addition to the Cloud project for your production\nbackend.\n\nDepending on the purpose of the environment or the stage in the API lifecycle,\nyou may want to:\n\n- Change the API name or the Cloud Endpoints service name. See [Configuring Endpoints](/endpoints/docs/openapi/configure-endpoints#service_name) for more information.\n- Create a different project.\n- Change the path that the API is served from.\n\nFollowing are some common patterns you may want to use:\n\n- **Versioning the API**: When you think you may need to make backwards-incompatible\n changes in the future, plan ahead and add the version number in the path where\n the API is served from. For example:\n\n - `my-api.endpoints.my‐project.cloud.goog/`**v1**`/echo`\n- **Development/test instances**: Each developer stands up their own version of the\n service, in their own project. For example, Dan the developer uses:\n\n - `my-api.endpoints.`**dan-dev-project**`.cloud.goog/v1/echo`\n- **Staging**: Before you deploy to production, you test your APIs on your\n staging backend, which is in its own project. For example:\n\n - `my-api.endpoints.`**my‐project-staging**`.cloud.goog/v1/echo`\n- **Running a private alpha**: When you want to test a new version of your\n service with some customers, but not all, the easiest approach is to put the\n alpha version in its own project, which provides the highest level of isolation\n from production. For example:\n\n - `my-api.endpoints.`**my‐project-alpha** `.cloud.goog/`**v2alpha**`/echo`\n\n Alternatively, you could put the alpha version in the same project but\n configure it as a separate service. Since it is a separate service, you can\n restrict access to only the alpha customers. For example:\n - **my-api-alpha** `.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n- **Running an open alpha**: When you want to release an alpha version that\n is available to all customers, you can put it in the same service and project as\n the existing version, and change the path. For example:\n\n - `my-api.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n\nSee also:\n\n\u003cbr /\u003e\n\n- [API lifecycle management](/endpoints/docs/openapi/lifecycle-management)\n- [Versioning an API](/endpoints/docs/openapi/versioning-an-api)"]]