# getting-started-python: the sample code behind Google's Python cloud tutorials

> A collection of tutorial projects rather than a library, covering a bookshelf web app, background processing, Compute Engine deployment, Firestore sessions and IAP authentication, with a nox driven test workflow and encrypted secret handling.

**GoogleCloudPlatform/getting-started-python** — Code samples for using Python on Google Cloud Platform

- Repository: https://github.com/GoogleCloudPlatform/getting-started-python
- Website: https://cloud.google.com/python
- Stars: 819 · Forks: 571
- Language: Python
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/googlecloudplatform-getting-started-python

## Six tutorial folders, each tied to one product

The repository is the complete sample code for the Python Getting Started on Google Cloud Platform tutorials, and the project notes are explicit that the tutorials themselves hold the instructions for configuring, running and deploying the samples. The code for each sample lives in its own folder, and the README maps them in a table.

The `bookshelf` folder backs the Getting Started tutorial, which is the entry point where a simple web application is built and deployed. The `background` folder covers background processing. The `gce` folder is for deploying to Google Compute Engine. The `sessions` folder handles sessions with Firestore, and `authenticating-users` covers authenticating users with IAP.

One entry points elsewhere. Deploying to Google Kubernetes Engine is not in this repository at all; the README directs it to the `kubernetes-engine-samples` repository, in the `quickstart/python` folder of that separate project. That split is a reasonable division of labour, since a Kubernetes deployment sample has different prerequisites from the App Engine and Compute Engine ones, but it does mean the samples are spread across two repositories if you follow the whole table.

The `optional-kubernetes-engine/` directory at the top level is a separate thing from the external repository link. The visible file listing does not say what it contains, so it is best treated as a staging area for optional Kubernetes Engine pieces rather than something to depend on.

The audience is someone following a tutorial path rather than someone looking for a library. That distinction matters for what follows.

## The nox and pytest setup is the part worth copying

The most reusable content in the repository is the tooling, not the application code. The root of the repository carries a `noxfile.py` and a `pytest.ini`, and the development dependencies are pinned in `requirements.txt`:

```text
flake8===5.0.4; python_version < '3.8'
flake8==6.0.0; python_version >= '3.8'
pytest==7.3.1
nox==2023.4.22
requests==2.31.0
```

Two things stand out. The flake8 pin is conditional on the interpreter version, with 5.0.4 for Python below 3.8 and 6.0.0 from 3.8 upwards, which is the standard way of pinning two incompatible lint tool generations in one file. And nox is present as a dependency alongside pytest, meaning the test sessions are driven by nox rather than by calling pytest directly, with the noxfile deciding which Python versions and which combinations to run.

That pattern is worth copying even if you never touch a Google Cloud sample. Running a test suite across several interpreter versions and dependency sets through a declarative session file is a good default for a samples repository, because each sample folder tends to need slightly different pins and the matrix otherwise turns into a pile of shell scripts.

The CI configuration lives in `.kokoro/`, and `.trampolinerc` at the root is a Trampoline configuration file, which is Google's open source CI service. A `CODEOWNERS` file is present as well, which is how a large set of independent folders gets assigned for review.

## Encrypted secrets are shipped as a tarball, not as keys

The repository contains `secrets.tar.enc` along with `encrypt-secrets.sh` and `decrypt-secrets.sh` at the top level. That pairing is the interesting pattern.

An encrypted archive of secrets lives in version control, and the two scripts wrap the encryption and decryption of it. The design intent is that the plaintext credentials never enter the repository, while what the samples need can still be distributed reproducibly. A contributor decrypts the archive locally with their own key, gets the configuration the samples need, and runs against it.

The scripts are the point of the exercise rather than the archive itself. Anyone running the samples has to supply their own key, so the useful question is what the scripts do about handling it, and the visible documentation does not say. That is a gap worth closing before you rely on the workflow.

The two script names also imply the reverse operation exists, so a contributor who modifies the sample configuration can re-encrypt and propose an update to the archive. For a samples repository that has to keep working over time, that is the mechanism that prevents the archive from rotting as sample configuration changes.

What is not visible here is any policy on key distribution, rotation or expiry. For a repository you plan to use as a starting point rather than as a reference, replacing this mechanism with your own secret manager is the safer default.

## A tutorial sample and a production service are different objects

The clearest limitation of this repository is that every folder in it is a teaching artefact. That is its purpose, and the project notes do not pretend otherwise by pointing at the tutorials for the configuring, running and deploying instructions. But it does mean that some things a production service needs are simply absent.

There is no deployment configuration beyond what each sample needs for its own tutorial, no CI that builds and tests the deployed application, and no monitoring or alerting. The `CODEOWNERS` and Kokoro setup are about reviewing and testing the samples, not about operating them.

There is also a version currency issue that is easy to miss. The development pins are flake8 6.0.0, pytest 7.3.1, nox 2023.4.22 and requests 2.31.0. Those are the versions in the requirements file at the time of the last push, and the last push was on 2026-06-17. Pinning development tooling is good practice, but pinned tooling ages, and a new Python release will eventually be outside what these versions were tested against.

The samples themselves also encode the product surface of the moment they were written. If a Firestore session pattern or an App Engine runtime behaviour has changed since, the code will still run as written but might no longer be the recommended way to do it, which is the usual hazard of following a tutorial from a fixed commit.

## Why the tutorial pairing is the point

The alternative to this repository is not another code repository, it is the tutorial pages themselves, which pair prose with inline snippets. The difference between a snippet and a sample is that the sample is a running application with its dependencies, its configuration handling and its test session, and you can deploy it and see the result.

The value is highest for the folders where the wiring is the lesson. Handling sessions with Firestore means understanding how session state is stored and read, and a snippet showing one read does not show the whole path. Authenticating users with IAP is the same: the interesting part is the header handling and the trust boundary, which is much clearer in a complete sample than in a fragment.

Background processing is the third one worth singling out. The tutorial it accompanies covers running work outside the request cycle, and the code in `background/` shows the shape of that arrangement rather than a business logic example.

The `bookshelf` sample is the natural starting point in that list because it is the one the Getting Started tutorial builds from, and the README table lists it first.

For an engineer deciding whether to adopt a sample as a starting point for their own application, the useful question is whether their requirements match the product the sample was written for. If you are deploying to App Engine with Firestore behind it, the `bookshelf` and `sessions` folders are directly relevant. If you are on Kubernetes, the answer lives in the other repository.

## Conclusion

Adopt these samples if you are working through the Google Cloud Python tutorials and want working code for each step rather than snippets, or if you want a reference for how App Engine, Cloud Tasks, Firestore and IAP fit together in one application shape. Do not adopt them as a framework, since each folder is a tutorial artefact tied to a specific product and there is no shared library to depend on. Verify first which product each sample targets and which Python version it expects, and note that the secrets handling scripts expect a key you must supply yourself, since the encrypted archive in the repository cannot be opened without it.

## FAQ

### What does the getting-started-python repository contain?

It holds the complete sample code for the Python Getting Started on Google Cloud Platform tutorials, with each tutorial in its own folder: bookshelf, background, gce, sessions and authenticating-users, plus an optional-kubernetes-engine directory.

### Which Google Cloud products do the samples cover?

The table in the README maps Getting Started to bookshelf, Background Processing to background, Deploying to Google Compute Engine to gce, Handling Sessions with Firestore to sessions, and Authenticating Users with IAP to authenticating-users. The Kubernetes Engine quickstart is in the separate kubernetes-engine-samples repository.

### How are the tests run in getting-started-python?

The repository has a noxfile.py at the root and pytest.ini, and the requirements file includes pytest==7.3.1 and nox==2023.4.22, so test sessions are driven through nox rather than by calling pytest directly.

### How does the repository handle secrets?

It ships secrets.tar.enc together with encrypt-secrets.sh and decrypt-secrets.sh at the top level, so encrypted sample configuration can be distributed without committing plaintext credentials. A contributor needs their own key to decrypt it.

### Can I use these samples as a starting point for a production application?

They are teaching artefacts rather than a production template, and the README directs you to the tutorials for configuring, running and deploying. There is no deployment configuration beyond each tutorial's needs, and no monitoring or alerting setup.

## Sources

- [GoogleCloudPlatform/getting-started-python on GitHub](https://github.com/GoogleCloudPlatform/getting-started-python)
- [Issues](https://github.com/GoogleCloudPlatform/getting-started-python/issues)
- [License: Apache-2.0](https://github.com/GoogleCloudPlatform/getting-started-python/blob/main/LICENSE)
- [Project website](https://cloud.google.com/python)
- [README](https://github.com/GoogleCloudPlatform/getting-started-python/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlecloudplatform-getting-started-python