This page provides recommendations for naming conventions of the Cloud projects
that you may need to create in addition to the Cloud project for your production
backend.
Depending on the purpose of the environment or the stage in the API lifecycle,
you may want to:
Change the API name or the Cloud Endpoints service name. SeeConfiguring Endpointsfor more
information.
Create a different project.
Change the path that the API is served from.
Following are some common patterns you may want to use:
Versioning the API: When you think you may need to make backwards-incompatible
changes in the future, plan ahead and add the version number in the path where
the API is served from. For example:
my-api.endpoints.my‐project.cloud.goog/v1/echo
Development/test instances: Each developer stands up their own version of the
service, in their own project. For example, Dan the developer uses:
Running a private alpha: When you want to test a new version of your
service with some customers, but not all, the easiest approach is to put the
alpha version in its own project, which provides the highest level of isolation
from production. For example:
Alternatively, you could put the alpha version in the same project but
configure it as a separate service. Since it is a separate service, you can
restrict access to only the alpha customers. For example:
Running an open alpha: When you want to release an alpha version that
is available to all customers, you can put it in the same service and project as
the existing version, and change the path. For example:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eThis page offers recommendations for naming conventions of Cloud projects beyond the production backend project.\u003c/p\u003e\n"],["\u003cp\u003eOptions include modifying the API or service name, creating separate projects, or altering the API's serving path based on the API lifecycle stage.\u003c/p\u003e\n"],["\u003cp\u003eCommon patterns include versioning APIs by incorporating version numbers in the path, setting up dedicated projects for development/testing, and using separate projects for staging or alpha releases.\u003c/p\u003e\n"],["\u003cp\u003eFor private alpha releases, either a distinct project or a separate service within the same project can be used for isolation and restricted access.\u003c/p\u003e\n"],["\u003cp\u003eOpen alpha releases can reside in the same project and service as the existing version, but with a unique path.\u003c/p\u003e\n"]]],[],null,["# Planning Your Cloud Projects\n\n[OpenAPI](/endpoints/docs/openapi/planning-cloud-projects \"View this page for the Cloud Endpoints OpenAPI docs\") \\| gRPC\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/grpc/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`"]]
