genai-for-marketing: a Terraform-deployed Gemini and Vertex AI reference stack for marketing teams
Showcasing Google Cloud's generative AI for marketing scenarios via application frontend, backend, and detailed, step-by-step guidance for setting up and utilizing generative AI tools, including examples of their use in crafting marketing materials like blog posts and social media content, nl2sql analysis, and campaign personalization.
At a glance
- What is it?
- Google's genai-for-marketing repository is a reference implementation, not a library. It ships a frontend, backend APIs, Terraform infrastructure and Jupyter notebooks that demonstrate marketing use cases on Vertex AI. The core question for an engineering team is whether to deploy it as a starting point or read the notebooks and build separately.
- Who is it for?
- Adopt this if you want a working reference for Vertex AI in a marketing context and you are already on Google Cloud with Terraform in place. Do not adopt it if you need a maintained product with a versioned API, or if your data lives outside BigQuery, Looker and Google Workspace.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 86 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What genai-for-marketing actually is, and who it is for
The repository describes itself as resources enabling generative AI-powered marketing use cases on Google Cloud. That phrasing matters. This is not a pip-installable package, and it is not a hosted service. It is a deployable demonstration: a frontend, a set of backend APIs, Terraform scripts under /infra, workspace templates under /templates, and a notebooks directory that explains the underlying concepts.
The intended reader is a team that has already committed to Google Cloud and wants to see how Vertex AI, BigQuery, Looker and Google Workspace fit together for marketing work. The demonstrations listed in the README map to concrete jobs: Marketing Insights through Looker dashboards, an Audience and Insight Finder that translates natural language into SQL, Trendspotting on Google Trends data, Content Search via Vertex AI Search, and Content Generation using Vertex Foundation Models for email copy, articles, social posts and PMax assets.
If your team is deciding between cloud providers, this repository will not help you decide. Every path in it assumes BigQuery, Looker, Vertex AI and Workspace. The value is in seeing a complete wiring diagram rather than in the code itself.
The architecture is a demonstration harness, not a service boundary
The README points to an architecture diagram at /app/images/architecture.png and splits the code into /app (diagrams and images), /backend_apis, /frontend, /infra, /notebooks and /templates. That layout tells you the deployment is a single cohesive demo rather than a set of independently versioned services.
The data flow implied by the demonstrations runs in two directions. On the analytics side, natural language questions from the Audience and Insight Finder are converted to SQL against BigQuery, and Looker dashboards surface marketing data. On the generation side, Vertex language and vision models produce text and images, which can then be moved into Google Workspace for review in Slides, Docs and Sheets.
Because the notebooks are the primary language of the repository, the conceptual material sits alongside the deployable code rather than inside it. If you want to understand the nl2sql translation, you read /notebooks/data_qa_with_sql.ipynb. If you want to understand trend summarization, you read the LangChain agent notebook or the simpler PaLM version. The deployed application is the packaged form of those ideas.
Deploying with Terraform and the two configuration surfaces
The README directs readers to the deployment guide at /infra/README.md and states that deployment is done with Terraform. A walkthrough video is linked for the automated process. The repository does not publish a one-line install command in the material available here, so treat the deployment guide as the authoritative source.
Configuration happens in two places. Pre-deployment settings come from infra/variables.tf. The README is explicit about ordering: make changes to variables.tf prior to running terraform init, because changes made afterwards may result in unexpected behavior including irrecoverable deployment failures. That is a strong warning and worth taking literally. Terraform state created against one set of variables does not necessarily reconcile with a later edit.
The second surface is config.toml, which the README introduces under the Configuration section as a way to change some of the solution's behavior after deployment. The README text is truncated at that point, so the specific keys inside config.toml cannot be confirmed from the supplied material. Anyone planning to tune the deployed application should read that section in full before assuming which behaviors are adjustable.
The notebooks are the durable part, and they age fastest
Four notebooks ship in the repository. data_qa_with_sql.ipynb translates natural language into GoogleSQL for BigQuery. news_summarization_langchain_palm.ipynb uses LangChain agents and the ReAct pattern to summarize news around top search terms. simple_news_summarization.ipynb does the same job with the PaLM API directly. Imagen_finetune.ipynb covers fine tuning an Imagen model.
The naming is a signal. Two of the four reference PaLM by name, and the external notebooks linked from the README have since moved to Gemini. The repository's most recent release is v2.1.0, dated 2024-10-04, while the last push to the default branch is 2026-06-21. That gap between release tagging and branch activity is worth noting: the branch is moving, but the tagged releases are not keeping pace.
For a reader, the notebooks remain the clearest explanation of how the pieces connect. For anyone deploying, the notebook model references are the first thing to check against current Vertex AI model availability in your region. A notebook that runs against a retired model is documentation, not code.
Where the reference stack stops being the right tool
The repository is a demonstration, and it behaves like one. The clearest limitation is the dependency footprint: BigQuery, Looker, Vertex AI Search, Vertex Foundation Models and Google Workspace all appear in the demonstration list. A team that uses Snowflake for warehousing and a non-Google BI tool cannot deploy this without replacing the parts that matter most.
A second limitation is the absence of a stability contract. There is no published API surface, no compatibility policy and no deprecation schedule in the material. Releases are tagged as stable demos (v2.0.0 is labeled Stable demo v2.0.0), which is a different promise from a library that maintains backward compatibility across minor versions. If your application imports from /backend_apis, you are building on a moving target.
The third limitation is operational. Terraform will provision the infrastructure, but the README's own warning about irrecoverable deployment failures after editing variables.tf post-init suggests the lifecycle is not forgiving. This is a stack you stand up, study and adapt, not one you run in production and patch quarterly.
The honest alternative: build on the notebooks, skip the app
The most direct alternative is not a competing product. It is the upstream repository the README itself points to: GoogleCloudPlatform/generative-ai. Several of the supplementary notebooks linked from this repository live there, including the Gemini tuning examples, document summarization techniques, document Q&A, and the Vertex AI Search demos.
The difference in approach is scope. genai-for-marketing bundles a deployable application around marketing scenarios, with Terraform and a frontend. The generative-ai repository is a broader collection of notebooks organized by task, without the marketing-specific application shell. If your goal is to learn how to tune a model for brand voice, the generative-ai tuning notebooks are the shorter path. If your goal is to hand a working demo to a marketing organization, this repository saves you the assembly work.
A second alternative is to treat the notebooks here as specifications and implement the pieces you need against your own stack. The nl2sql notebook, for example, describes a translation pattern that does not depend on the rest of the deployment. Extracting that pattern is often faster than deploying the full application and then removing the parts you do not want.
Maintenance cost and the Apache-2.0 licence in practice
The repository is licensed Apache-2.0, which permits commercial use, modification and redistribution provided you retain the licence and notices, and it includes a patent grant. That is a permissive licence, and it is the same licence used across much of Google's sample code. Nothing in the material suggests additional restrictions on the code itself.
The licence does not cover the services the code calls. Vertex AI, BigQuery, Looker, Vertex AI Search and Google Workspace are billed products with their own terms, and deploying this stack will incur charges in your Google Cloud project. That distinction is easy to miss when a repository is free to clone.
Maintenance cost is harder to estimate from the material. The release cadence shows v1.1.1 and v2.0.0 both tagged on 2024-04-05, then v2.1.0 on 2024-10-04. The default branch has commits as recent as 2026-06-21. Whether those commits are dependency bumps, model name updates or feature work cannot be determined from the supplied information. Anyone adopting this should plan to track the branch rather than the releases, and should expect to update model identifiers as Vertex AI model availability changes.
Editorial conclusion
Adopt this if you want a working reference for Vertex AI in a marketing context and you are already on Google Cloud with Terraform in place. Do not adopt it if you need a maintained product with a versioned API, or if your data lives outside BigQuery, Looker and Google Workspace. Before deploying, read infra/variables.tf and confirm the defaults match your project, then verify the model names referenced in the notebooks still resolve in your region.
Community notes