TL;DR — Rodosto Teknoloji attended the 2026 Esri Türkiye Partners Meeting. Our Founder Onurhan Şeremet, together with Solutions Specialists Damla Kocaman and Eylül Kaya, joined a day of platform sessions, partner case studies, and conversations with the Esri Türkiye team and the wider ecosystem. A short note on what the gathering is, why we were there, and what it changes for the work we do next.

The Esri Türkiye Partners Meeting — held on 13 May 2026 in Ankara — is the annual gathering where Esri Türkiye and the partner organisations building on the ArcGIS platform meet to review the platform roadmap, share project results, and align on the year ahead. As a member of the Esri Partner Network, Rodosto attended this year’s edition.

This was not a sales event. It was a working session for the people who deliver ArcGIS programmes in Turkey — municipal GIS managers’ vendors, utility integrators, enterprise consultancies, and the Esri Türkiye product and technical teams who support them. The point of the day was to compare notes on what works, what is changing in the platform, and where the partner community is heading.

Who attended from Rodosto

Three of us represented Rodosto at the meeting:

• Onurhan Şeremet — Founder
• Damla Kocaman — Solutions Specialist
• Eylül Kaya — Solutions Specialist

The composition was deliberate. The founder is in the room for the strategic and partner-relationship conversations; the solutions specialists are in the room for the technical sessions and the case-study exchange that directly informs how we scope and deliver projects. The two layers feed each other — the partnership decisions we make at the top of the company only matter if they translate into how our delivery team works on Monday morning.

Why we were there

Three reasons, in order of how much they shape what happens next at Rodosto.

1. The platform roadmap

ArcGIS is not a static platform. ArcGIS Enterprise, ArcGIS Online, the Experience Builder line, the Velocity and Knowledge extensions, and the developer SDKs all move on their own cadence. For a partner that designs and delivers solutions on this stack, sitting in the room when the roadmap is presented is materially different from reading the release notes after the fact. Questions get asked. Edge cases get clarified. The implicit ordering of priorities — what Esri sees as the centre of gravity for the next year — comes through in the tone of the sessions, not the slide bullets. That signal is hard to acquire any other way.

2. Partner case studies

The most useful sessions at a partner meeting are the ones where another partner walks through a real deployment — the architecture, the trade-offs, the things that went wrong, the things that surprised them after go-live. The audience is the only audience qualified to ask the questions that matter, because everyone in the room has run a project that looked something like the one being presented. The case-study exchange compresses lessons that would otherwise take years of independent project work to accumulate.

3. The partner community

The Esri Türkiye partner ecosystem is not a competitive arena where every firm guards its work. Most projects of any meaningful scale touch more than one partner — a system integrator, a data provider, an application developer, a training organisation. Knowing who does what well, who is reliable, and who is a good fit for a given client’s constraints is the kind of context that only the partner channel can give. The networking block exists for a reason.

What we took away

A partner meeting is most useful when the takeaways are operational, not aspirational. Three things we are carrying into the next quarter of work:

• Reinforced alignment with Esri Türkiye. Direct conversations with the Esri Türkiye technical and partner teams shorten the loop on the support, licensing, and roadmap questions that come up in every serious enterprise GIS project. The relationship is now a phone call, not a ticket queue.
• Sharper picture of the partner ecosystem. Where we previously knew partners by their public profile, we now know them by face and by the projects they actually run. That changes how we recommend collaboration to clients whose needs span more than one specialism.
• Confirmation that our delivery focus is well calibrated. Our core focus — ArcGIS Enterprise deployments, integration with operational systems, custom tools and widgets, field data collection, and security and governance — lines up with where the Turkish market is investing. The meeting did not surface a gap; it surfaced a series of opportunities to go deeper on what we already do.

Thank you

Thank you to the Esri Türkiye team for organising the meeting and for the substance of the sessions, and to the partner organisations in the room for the conversations that filled the day around them. The work we do at Rodosto sits inside a wider ecosystem, and gatherings like this one are what keep that ecosystem coherent.

If you are a municipality, public institution, utility, or enterprise considering an ArcGIS-based programme — whether a new platform, an integration into existing operational systems, or a governance and security layer on top of what you already run — we would be glad to talk. Reach us at hello@rodostoteknoloji.com.

TL;DR — On the ArcGIS platform, almost anything is possible — which makes “can we build this?” the wrong question. The right one is “at which build tier?” ArcGIS offers three: configurable apps (Instant Apps), low-code (Experience Builder), and custom development (the ArcGIS Maps SDKs and APIs). Most teams choose wrong in one of two directions and pay for it in months. This is the framework for choosing right.

Teams come to us with a screenshot of an application they want — a public map, a dashboard, a field tool, a portal — and they ask the same question: can ArcGIS do this? The answer is almost always yes. ArcGIS is a deep platform; the ceiling is high enough that for most municipal, utility, and enterprise needs it is not the constraint.

The expensive question is the one they do not ask: at what build tier should this be done? Choose a tier too low and you spend the back half of the project fighting a tool’s ceiling. Choose a tier too high and you spend a six-figure budget building, and then maintaining, software that a configuration wizard would have produced in an afternoon. Both mistakes are made at the very start — on a whiteboard, before anyone writes a line of code.

This post lays out the three tiers of building on the ArcGIS platform, and a framework for placing your project on the right one.

The Three Tiers of Building on ArcGIS

Every application built on ArcGIS sits at one of three levels of engineering effort. They are not ranked by quality — a well-chosen Tier 1 app is a better outcome than an unnecessary Tier 3 one. They are ranked by how much you build yourself, and therefore how much you own.

Tier 1 — Configurable Apps (ArcGIS Instant Apps)

You start with a web map or scene, choose a purpose-built template from ArcGIS Instant Apps, configure it through a wizard, and publish. There is no code. The output is a focused, responsive, accessible application delivered in minutes to hours.

The strength of Tier 1 is everything you do not have to do. Esri maintains the app; platform upgrades reach it for free; accessibility and responsive behavior are handled. There is no codebase, no pipeline, and no maintenance contract. The limit is equally clear: you get the template’s layout and feature set. You cannot invent a screen the template does not offer, fundamentally change the interaction model, or integrate a non-ArcGIS system in a deep way.

Tier 1 is the right answer when the deliverable is a focused viewer or explorer — a public information map, a before-and-after comparison, a nearby-search, a media-driven sidebar map — and the data already lives in ArcGIS. For a large share of public-facing municipal maps, this tier is not a compromise. It is the correct engineering decision.

Tier 2 — Low-Code (ArcGIS Experience Builder)

ArcGIS Experience Builder is a widget-based, drag-and-drop environment. You compose pages from widgets — maps, lists, charts, filters, tables — control the layout, apply theming and branding, and build multi-page experiences with conditional content. It runs in both ArcGIS Online and ArcGIS Enterprise.

Experience Builder is far more flexible than Instant Apps. It is the tier where a real application takes shape: branded dashboards, multi-step workflows, internal operations portals. A note for teams with older ArcGIS experience — Web AppBuilder has been retired, and Experience Builder is its designated successor. New work should target Experience Builder, not Web AppBuilder, regardless of what an existing deployment still runs.

There is also a genuine middle ground worth knowing: Experience Builder Developer Edition lets a developer build custom widgets and self-host the result. It is a real bridge between Tier 2 and Tier 3 — most of the application is assembled, with custom code only where the requirement demands it.

The limit of Tier 2 is that it remains a widget framework. A UX that does not map cleanly onto assembled components, deep interactions, heavy non-ArcGIS integration, or pixel-exact product design will eventually press against the framework’s edges. Tier 2 is the right answer when the deliverable is a real application, but its interaction model still fits a composition of components.

Tier 3 — Custom Development

Tier 3 is software development. You build the application yourself — every screen, every interaction, every integration — with ArcGIS as the spatial engine and service backend inside it. The toolset is the ArcGIS Maps SDK for JavaScript for the web, the native Maps SDKs (Swift, Kotlin, .NET, Qt) for mobile and desktop, the ArcGIS REST API as the integration contract, and the ArcGIS API for Python for automation and geoprocessing.

Tier 3 has no ceiling. Any user experience, any integration, any performance profile, a complete white-label, or mapping embedded directly inside an existing product — all of it is reachable here, and only here. The cost is that it is software, with everything that implies: developers, a codebase, testing, a deployment pipeline, and ongoing maintenance, including keeping current with SDK releases.

Tier 3 is the right answer when the application is a product or a load-bearing internal system, when the UX cannot be expressed as assembled widgets, when deep integration with non-ArcGIS systems is central to the requirement, or when mapping has to live inside an application you already own.

How to Choose the Right Tier

The rule is short: start at the lowest tier that fully meets the requirement, and only move up when a specific requirement forces you to. The discipline is in being honest about what actually forces the move — not what feels more impressive to build.

The Questions That Force You Up a Tier

Run the requirement against this checklist. If the answer to any question is yes, you are probably one tier higher than you first assumed:

• Does the user experience need a screen or an interaction the tool does not offer?
• Does it integrate deeply with a non-ArcGIS system — an ERP, an identity provider, a custom database, a third-party API?
• Does it need to be fully white-labeled, so it does not read as an Esri-built app?
• Does it need a true offline mode or a native mobile experience?
• Does mapping have to be embedded inside an application you already operate?
• Are there performance requirements at a scale the configured tool was not designed for?

One yes typically moves you from Tier 1 to Tier 2, or from Tier 2 to Tier 3. Several yeses point to Tier 3 without much further debate. If every answer is no, resist the pull upward — the lower tier is not a lesser outcome, it is a lower-risk one.

The Mistake in Both Directions

Under-building is the more common failure. A team picks Experience Builder because it is included and fast, then discovers mid-project that the requirement really needed custom code. The back half of the schedule is spent bending widgets into shapes they were never meant to take. The app ships late, brittle, and expensive to change — and the team has a low-code project with a high-code cost.

Over-building is less common but more expensive per occurrence. A team commissions a custom JavaScript application — a codebase, a pipeline, a maintenance contract — to deliver what is, in the end, a public viewer. An Instant App would have produced it in an afternoon and Esri would have maintained it for free. Instead the team now owns software it did not need, and will pay to keep alive for as long as it runs.

Both mistakes are made before implementation begins. That is the case for taking the tier decision seriously as its own step, with its own analysis, rather than defaulting into it.

What “Custom Development” Actually Involves

If your project lands on Tier 3, it helps to know what you are actually authorizing — especially if you are the one signing for it rather than writing it.

The toolset. Web applications are built on the ArcGIS Maps SDK for JavaScript. Native mobile and desktop apps use the platform-specific Maps SDKs. The ArcGIS REST API is the contract every integration is written against. The ArcGIS API for Python handles automation, batch geoprocessing, and the data-engineering work behind the app. A Tier 3 project usually touches more than one of these.

The team. Custom ArcGIS development needs front-end engineers fluent in the Maps SDK, someone who genuinely understands the ArcGIS service model — feature services, token-based authentication, the REST API — and enough spatial-data knowledge to model the data correctly in the first place. A capable web developer without the ArcGIS-specific knowledge will produce an app that works in a demo and struggles in production.

The maintenance reality. Custom code is an asset and a liability at the same time. The SDK releases on a regular cadence; an ArcGIS application that nobody maintains drifts out of support like any other software. A Tier 3 budget that covers the build but not the maintenance is an incomplete budget.

The deployment. A custom app is web infrastructure — hosting, a build pipeline, and an authentication strategy for ArcGIS tokens. None of it is exotic, but all of it is real, and it is the part teams forget when they compare a custom build against a “free” Experience Builder app. The honest comparison includes the operational tail, not just the first release.

Where Rodosto Fits

Rodosto Teknoloji is a member of the Esri Partner Network, and the company was founded by a GIS engineer who is a published author on the ArcGIS JavaScript SDK and Web GIS architecture. Tier 3 — custom development on the ArcGIS platform — is our home ground. But the advice we give a client almost always starts a tier lower than they expect.

The first thing we do on any application engagement is the triage described above: take each requirement, place it on the tier that genuinely fits, and recommend the lowest tier that holds. Often that means telling a client they do not need the custom application they walked in asking for — that an Instant App or an Experience Builder configuration will meet the requirement at a fraction of the cost and none of the maintenance. Sometimes it means the opposite: that the low-code app they planned will not survive its own requirements, and the honest answer is custom development from the start.

When the answer is Tier 3, we build it — on a Discover, Architect, Build, Deploy cadence, with the security-first, services-not-files engineering that the rest of our work runs on. The deliverable is an application the client can operate, not a dependency on the people who wrote it.

If you are looking at a screenshot of what you want and wondering how to build it on the ArcGIS platform, the tier decision is the first conversation worth having. Get in touch and we will run the triage with you.

Rodosto Teknoloji is now a member of the Esri Partner Network. For the municipalities, utilities, and enterprises we work with, that means certified access to the full ArcGIS platform, a direct channel to the company behind the technology, and an independent signal that the engineering standard we hold ourselves to is real. Here is what the membership is, what it changes, and what it deliberately does not.

We will state it plainly: Rodosto Teknoloji is a member of the Esri Partner Network. Rodosto has built on the ArcGIS platform since the day the company was founded — the expertise was always there. What is new is that the relationship is now formal, recognized, and verifiable by the people who matter most: the procurement officers, GIS managers, and information-security reviewers who decide which vendor a public agency or enterprise will trust with its spatial infrastructure.

An announcement like this can easily become a vanity post. We would rather it be useful. So this is not a celebration — it is an explanation of what the membership actually means for an organization deciding whether to work with us.

What the Esri Partner Network Is

Esri is the company behind ArcGIS — the platform that the majority of serious municipal, utility, and government GIS programs run on. The Esri Partner Network is Esri’s global program of organizations that design solutions, deliver services, and build products on that platform. It is a vetted relationship, not a directory listing. Membership ties a firm into Esri’s technical resources, release cadence, and partner channels.

For a buyer evaluating a GIS vendor, the membership answers one specific and reasonable question: is this firm recognized by the company that makes the platform it claims expertise in? A consultancy can describe itself however it likes on its own website. Membership in the Esri Partner Network is a statement made by a third party — and third-party statements are the only ones that carry weight in a procurement file.

Why This Matters for the Organizations We Serve

The membership is not an abstraction. It changes four concrete things about how a project with Rodosto runs.

1. Certified Access to the Full ArcGIS Platform

ArcGIS is not a single product. It is a platform — ArcGIS Enterprise, ArcGIS Online, ArcGIS Pro, Experience Builder, the developer SDKs, and the geoprocessing and automation surfaces around them. Partner membership means Rodosto works with current, licensed, supported access to that full platform. Solutions are engineered, tested, and validated against the real software an agency will run in production — not against an approximation of it.

2. A Direct Channel to the Vendor

Every non-trivial GIS project eventually hits a platform-level question — a deprecation, an undocumented limit, a behavior that needs confirmation from the source. As an Esri Partner Network member, Rodosto reaches Esri’s technical and partner resources through an established channel rather than waiting on a public forum. For the client, that is the difference between a blocker that stalls a phase and a question that is answered and closed.

3. Current Platform Knowledge

ArcGIS evolves on a fast release cadence. Capabilities are added, patterns are deprecated, and the recommended architecture shifts from one version to the next. Partner status keeps Rodosto inside that release stream — early visibility into what is changing, what is being retired, and where the platform is heading. An architecture we design today is built to be defensible against the platform of the next few years, not just the current one.

4. An Independent Credibility Signal

For public-sector buyers in particular, “Esri Partner Network member” is a line that a procurement committee, a council, or an auditor recognizes without needing it explained. It does not replace technical evaluation — nothing does — but it removes a category of doubt early in the process. It tells a cautious buyer that the firm in front of them operates inside the platform’s recognized ecosystem.

TL;DR — Open geospatial data is now an expectation, not a favor. Public agencies that publish parcels, roads, utilities, and environmental layers in 2026 are also expected to know — on demand — who consumed which dataset, when, and at what rate. This playbook describes the architecture that lets agencies meet both expectations: a single authoritative source on the inside, a governed gateway on the perimeter, and a queryable audit trail behind every outbound byte.

The open data movement assumed that publishing a dataset and walking away was the end of the operator’s job. That assumption stopped being true once open data started being load-bearing. When a citizen-facing app, a contractor’s field tool, a partner agency’s dashboard, and a researcher’s notebook all consume the same parcel layer, the dataset has crossed from “publication” to “production.” And production data needs the same accountability surface that every other production system in the agency already has.

The good news: the architecture that gets an agency there is well understood. The pieces are the same pieces that the rest of a modern ArcGIS Enterprise deployment uses — just composed in a way that makes outbound openness an operational property, not an accident.

The Open Data Dilemma in One Picture

Imagine a typical municipal scenario. The agency publishes ten public-facing layers on a download portal: parcel boundaries, zoning, addresses, road centerlines, public-transit stops, water and sewer mains (redacted), street trees, parks, building footprints, environmental coverage. Each layer is a dataset that downstream consumers actually depend on.

Now ask the questions that any internal information-security review will eventually ask:

• How many distinct external systems are reading the parcel layer this month, and which of them are the top three by request volume?
• If a single consumer began pulling the building-footprint layer at ten times its historical rate, would the agency notice in real time, or in the next quarterly report, or never?
• If a regulator asks for a record of every download of a redacted utility layer in the past twelve months, can the agency produce that record in one query?
• If a partner contract ends, does the agency have a mechanism to revoke that partner’s access without breaking access for the other consumers of the same layer?

For most public agencies in 2026, the honest answer to each of those questions is some shade of “not really.” That is the gap. Open data without operational risk is the architecture that closes it.

The Four Properties of Governed Open Data

Governed open data is not less open. It is not slower. It is not harder to consume. It is open data with four extra properties that the publishing agency — not the consumer — benefits from.

1. Authoritative Source on the Inside

There is exactly one official copy of every open dataset, sitting inside the agency’s ArcGIS Enterprise environment, owned by the department that produces it. The open feed is a derivative of that authoritative source — not a parallel, unsanctioned copy. This is the same single-source-of-truth principle that the Municipal GIS Playbook describes for internal consumption. Open data inherits it; it does not replace it.

2. A Governed Perimeter on the Outside

Outbound consumption flows through a single perimeter layer that does four things on every request: identifies the consumer, validates the request against an allowlist, applies a rate limit, and writes a structured audit record. This is the same governance pattern Rodosto detailed in Proxy Token Manager — Secure ArcGIS Enterprise Services. The mechanism is identical for partner-only services and for fully open public services. The only difference is the policy attached to the consumer record.

3. A Queryable Audit Trail

Every request is recorded as a row in a database the operator can query. Timestamp, consumer identity, request path, source IP, status code, response time. Retention is configurable per organization, from a short window for low-sensitivity layers to multi-year retention for layers that touch regulatory or legal review. The audit trail is the evidence that turns “we publish openly” into “we publish openly and we can prove it.”

4. Lifecycle Without Manual Effort

Tokens expire on schedule. Rate limits adjust through configuration, not code. Decommissioned consumers stop receiving traffic the moment the operator marks them inactive. Configuration changes propagate to the gateway automatically — the operator does not edit NGINX files by hand at midnight. The system runs itself between deliberate operator interventions.

The Reference Architecture

Inside: The Authoritative Source

Open datasets live inside ArcGIS Enterprise as feature services, image services, or vector tile services, federated with Portal for ArcGIS and backed by an enterprise geodatabase on PostgreSQL or Microsoft SQL Server. The dataset is owned by the producing department, sharing is controlled through Portal groups, and the derivative open feed is registered as a service whose source is unambiguous. Nothing about the open distribution requires bypassing or duplicating the internal model.

The Perimeter: Gateway, Tokens, Allowlists

Between the internal services and the outside world sits a gateway layer. For partner-only or contractor-only feeds, the gateway issues per-consumer tokens with referrer and IP allowlists, exactly as described in the Proxy Token Manager reference. For fully open public feeds, the gateway issues per-application tokens (one per consuming application, anonymous to the human user) and applies a rate limit calibrated against the upstream service’s capacity.

The point is not to gate access. The point is that every request, even an anonymous one, is attributable to some consumer record — an application, a tenant, a partner — so that anomalies are detectable and policy is enforceable.

Audit and Telemetry

Every request through the gateway is written twice: once as a structured row in an audit table (PostgreSQL is the conventional choice; the Proxy Token Manager reference architecture uses it), and once as a structured JSON line on the application log stream for ingestion into Loki, Elasticsearch, CloudWatch, Datadog, or whatever centralized observability the agency already runs. The two destinations serve two audiences: the audit table answers compliance questions, and the log stream feeds the operational dashboards.

Rate Limiting and Capacity Protection

Per-consumer rate limits prevent any single integration — intentional or accidental — from consuming a disproportionate share of the upstream ArcGIS Server capacity. A common failure mode for unrate-limited open feeds is an enthusiastic developer’s notebook that hits the parcel service in a tight loop and degrades performance for every other consumer. Rate limits at the perimeter make that failure mode impossible without operator awareness, because the rate-limited consumer’s requests appear in the audit log with a 429 status code that the dashboard surfaces immediately.

Lifecycle Automation

Token expiry, allowlist changes, retention pruning, and gateway configuration regeneration all run on schedule. The operator’s job is policy, not plumbing. New consumer onboarding produces an artifact — a per-consumer onboarding PDF with an API key, the assigned service paths, the rate limit, and copy-paste integration code for the ArcGIS JavaScript SDK, Leaflet, and OpenLayers — that compresses what was once a week of email into a calendar invite.

How Open Data Composes With the Rest of the Platform

The architecture above does not exist in isolation. It is the outbound face of the same ArcGIS Enterprise core that the agency runs internally. Three places it composes cleanly with the rest of the stack:

• Identity. Internal consumers authenticate against the agency’s identity provider (Azure Entra ID, Okta, ADFS) through Portal for ArcGIS. External consumers authenticate against the gateway’s consumer registry. The two registries do not have to merge — they have to be reconcilable, so an internal team can confirm that a given external partner is the same legal entity that signed the data-sharing agreement.
• Service tier. The same service that an internal department reads through Portal is the service that the gateway proxies to external consumers. There is no separate “open data” service that can drift from the authoritative version.
• Operations. The audit table and the log stream feed the same observability platform that the rest of the agency’s IT runs against. Open data outages are detected, triaged, and resolved on the same on-call rotation as any other production system.

For a deeper view of where these pieces sit inside the full ArcGIS Enterprise topology — data tier, service tier, portal and identity, governance perimeter, integration tier — see the Municipal GIS Playbook. This post is the outbound chapter of that playbook.

Common Failure Modes

Open data programs that do not adopt the architecture above tend to fail in predictable ways. A short list, in order of frequency:

• Static download URLs that nobody owns. A zipped shapefile published on a forgotten subdomain three years ago that thirty downstream systems still depend on, with no mechanism to deprecate, version, or audit. Every public agency has at least one of these. The right response is to bind that URL to the gateway and put a known consumer record behind every download.
• An “open” service with no consumer registry. If the gateway records a request as “anonymous” with no application-level identity, the audit trail is fictional. The right response is to require even open consumers to register an application token, however lightweight that registration is.
• Audit logs only in the proxy’s access log. NGINX access logs were not designed for compliance evidence. The audit trail belongs in a queryable database with a defined schema and retention policy — not in a flat file that gets rotated and lost.
• No rate limit on the parcel service. Parcel layers are the single most-abused open dataset in municipal GIS, because they are useful and because they are large. An open parcel service without a rate limit will, eventually, be hammered by an automated client and will degrade for every other consumer. Rate limits are not optional.
• Manual NGINX edits. If the operator opens a config file by hand to add a consumer, the configuration drifts and the disaster-recovery plan becomes fictional. Configuration regeneration belongs in code, not in muscle memory.

Implementation Cadence

The path from “we publish openly with no governance” to “we publish openly with a defensible audit trail” is a phased program, not a rewrite. The cadence:

Discover

Inventory the existing open feeds — download URLs, public services, embedded maps, partner integrations. For each feed, identify the producing department, the legal basis for publication, and the known consumers. Most agencies are surprised by how long this list is and by how little of it is documented anywhere centrally. The deliverable is a written inventory.

Architect

Design the gateway topology, the consumer registry schema, the audit retention policy per dataset, and the cutover sequence. Decide which feeds go first and which can run in parallel during migration. Produce an architecture document and a cutover plan that names every existing consumer to be migrated.

Build

Stand up the gateway in production, behind a feature flag if necessary, and migrate feeds one at a time. Each migrated feed gets its own consumer registry entries, rate limits, and audit retention policy. Avoid big-bang migrations — they fail public-procurement scrutiny and they fail consumers.

Deploy

Cut consumers over to the new gateway URLs with explicit parallel-run windows, train operators, and establish ongoing review cycles for the audit log. The deliverable is an agency that operates its own open data perimeter, not a dependency on the integrator.

Where Rodosto Fits

Rodosto Teknoloji designs and builds governed open data perimeters on top of existing ArcGIS Enterprise deployments for municipalities, regional authorities, central-government agencies, and private operators that publish geospatial data to partners or the public. The work is the same in every case: an inventory of what is already exposed, a gateway that brings every outbound request under one consumer registry, an audit trail that answers compliance questions in one query, and an operational handoff that leaves the agency running its own platform.

If your agency publishes geospatial data and the architecture above does not match what you have today, that gap is the work.

TL;DR — Modern municipal GIS is no longer a map department; it is a foundational data platform that every line of business in a city government depends on. This playbook describes the architecture public agencies should adopt in 2026: a federated ArcGIS Enterprise core, a governed service perimeter, a cloud-native deployment model, and an implementation cadence that survives the rhythm of public procurement.

Most municipal GIS programs were built one layer at a time. A parcel file came from the tax office. A road network arrived from public works. A zoning map was drawn in the planning department. Each department owned its data, its software, and its people. That model worked when a map was a deliverable. It does not work when a map is a service — consumed by permit portals, field inspection apps, utility SCADA dashboards, 311 systems, and public-facing viewers that the city’s citizens treat as a product.

Public agencies that have crossed the threshold from “map department” to “geospatial platform” share a common architecture. This post lays it out.

What Modern Municipal GIS Looks Like

A mature municipal GIS is not defined by the number of layers it holds. It is defined by five properties, each of which corresponds to a specific architectural decision.

1. A Single Authoritative Source for Every Dataset

There is exactly one official parcel layer. There is exactly one official road centerline. There is exactly one official address point dataset. Every downstream consumer — internal or external — reads from that source or from a sanctioned derivative. The moment a second, unsanctioned copy of the parcel layer appears on an engineer’s desktop, the governance model has failed and the cleanup cost compounds for years.

2. A Federated ArcGIS Enterprise Core

The authoritative data is published through ArcGIS Enterprise — Portal for ArcGIS federated with one or more ArcGIS Server sites, backed by ArcGIS Data Store and an enterprise geodatabase on PostgreSQL or Microsoft SQL Server. Federation is not a technical detail; it is the governance mechanism that ties identity, sharing, and content management together across the entire GIS stack. A federated Enterprise means a single sign-on, a single content catalog, and a single place to reason about who has access to what.

3. Services, Not Files, as the Unit of Delivery

Nothing is shipped as a shapefile or a file geodatabase. Every dataset is published as an ArcGIS Feature Service, Map Service, Image Service, or Vector Tile Service. Downstream systems consume those services over HTTPS with authenticated tokens. Files are generated on demand, as a derivative of the authoritative service — never as the source of truth. This single decision collapses dozens of ad-hoc data-delivery workflows into one uniform pattern.

4. A Governed Perimeter for External Consumption

Agencies share data with contractors, partner authorities, and the public. That sharing sits behind a governance layer: per-consumer API tokens, referrer and IP allowlists, per-request audit logs with queryable retention, and rate limits calibrated to the upstream service’s capacity. The goal is not to prevent sharing. The goal is to make sharing provable — so the GIS operator can answer, in one query, which consumer accessed which service on which date.

5. Cloud-Native Deployment with Infrastructure as Code

In 2026 the default deployment target for new municipal GIS programs is a public or sovereign cloud, provisioned through declarative infrastructure (Terraform, CloudFormation, or the agency’s internal IaC platform). The benefits that moved the rest of government IT to the cloud — reproducibility, disaster recovery, elastic capacity, reduced operational tax — apply to ArcGIS Enterprise without modification. On-premises deployments still have a role in classified or air-gapped contexts, but for the typical municipal workload the cloud has won.

The Reference Architecture

Data Tier

An enterprise geodatabase on PostgreSQL (with the PostGIS extension enabled for non-ArcGIS access paths) is the canonical store for authoritative municipal data. ArcGIS Data Store handles tile and scene caching, relational storage for hosted feature services, and spatiotemporal data for IoT and real-time feeds. Backups, point-in-time recovery, and cross-region replication are configured at the database layer, not the application layer.

Service Tier

ArcGIS Server sites, federated with Portal for ArcGIS, expose the data as services. Production municipal deployments typically run at least three Server sites:

• A hosting site — backed by Data Store, serving hosted feature and tile services.
• A reference site — serving read-only published services from the enterprise geodatabase.
• A raster site — serving orthoimagery, elevation, and image services, often with its own compute profile.

Separating service types across Server sites lets the agency tune compute, scale independently, and contain outages.

Portal and Identity

Portal for ArcGIS is the content catalog, the sharing surface, and the identity boundary. Production portals integrate with the agency’s enterprise identity provider (Azure Entra ID, Okta, or an on-premises ADFS) through SAML or OpenID Connect. Named-user licensing, role-based access control, and group-based sharing all flow from the identity layer — not from a local user table managed by the GIS operator.

Governance Perimeter

Public-facing services sit behind a governance layer that handles per-consumer authentication, audit logging, and rate limiting. This layer is the accountability surface between the agency’s internal ArcGIS deployment and everything that consumes it from outside. It is also the layer where compliance evidence is generated — the queryable audit trail that internal security teams and external auditors will eventually ask for.

Integration Tier

Every municipal GIS connects, at minimum, to a permit system, a work-order system, a public-facing 311 or service-request platform, and the finance and asset-management systems that depend on location. Those integrations are not point-to-point FTP jobs. They are declarative, observable data pipelines — typically built around the ArcGIS REST API, ArcGIS Data Interoperability, or a workflow engine like Apache Airflow — with clear lineage and the ability to replay a failed run.

What a Serious Municipal Deployment Costs — and What It Returns

Procurement officers are right to be skeptical of ROI claims in GIS. The honest answer is that the returns are real, but they are diffuse — spread across many departments, many workflows, and many years. The public record does contain credible numbers:

• Camrose County, Alberta, reported approximately CAD 63,000 in annual savings and a 233% ROI after replacing paper-based municipal workflows with a cloud-based GIS platform, according to a published PSD Citywide case study.
• The Municipal Authority of Westmoreland County replaced days of project-status reporting with minutes, and elevated data-accuracy confidence across engineering and operations, using ArcGIS Web AppBuilder, Operations Dashboard, and ArcGIS Collector.

The common pattern is that the largest returns come not from the GIS system itself, but from the other systems the GIS platform makes more accurate. When the permit system reads authoritative parcel data directly from a feature service, permit errors drop. When field crews capture work orders in an app backed by the same feature service, back-office reconciliation drops to zero. When the finance system ties asset values to authoritative asset geometries, audit findings drop. The GIS is rarely the line item with the biggest savings; it is the line item that makes every other line item cheaper.

An Implementation Cadence That Survives Procurement

Public procurement is slow for good reasons. A municipal GIS program has to be built in phases that each deliver verifiable value, so that the next phase can be defended to a council, a procurement committee, or an auditor. The cadence that works:

Discover

Audit existing systems, catalog data sources, interview the five or ten people in the agency who actually depend on geospatial data. Produce a written inventory of layers, owners, consumers, and known problems. This phase is short (weeks, not months) and its deliverable is a document, not software.

Architect

Design the authoritative data model, the federated Enterprise topology, the identity integration, the service portfolio, and the governance perimeter. Decide the cloud or on-premises target and the infrastructure-as-code substrate. Produce an architecture document, a deployment plan, and a cutover plan that names every downstream system that will be migrated from legacy data sources to the new services.

Build

Stand up the Enterprise environment in iterative cycles, typically one authoritative dataset at a time. Each iteration ends with a production-quality service, a migrated consumer, and a documented outcome. Avoid big-bang migrations — they are indefensible in a procurement context and they rarely survive contact with the agency’s operational reality.

Deploy

Cut consumers over to the new services with explicit parallel-run windows, train the operators who will run the platform after the integrator leaves, and establish the long-term support contract. The deliverable of the Deploy phase is an agency that can run its own GIS — not a dependency on the integrator.

Common Failure Modes

Municipal GIS programs fail in predictable ways. A short list, in order of how often we see them:

• Shapefiles in the architecture. If any production integration ships a shapefile or a file geodatabase as the unit of exchange, the authoritative-service model has leaked and the program is already drifting back to the old pattern.
• Local user accounts in Portal. If the GIS operator is creating users in Portal by hand instead of sourcing them from the agency’s identity provider, the access model is not governable and the first security review will say so.
• No audit trail on public services. If the answer to “who accessed this feature service last Tuesday” requires grepping NGINX logs, the answer is effectively “we do not know,” and that answer is no longer acceptable to information-security reviewers.
• A single monolithic ArcGIS Server. One Server site doing hosting, reference, and raster at the same time will be capacity-planned around the worst-case workload and will still fail during the next aerial-imagery refresh.
• No infrastructure as code. If the only way to rebuild the Enterprise environment is a senior engineer’s memory, the environment is not recoverable and the disaster-recovery plan is fictional.

Where Rodosto Fits

Rodosto Teknoloji designs and builds exactly this kind of platform for municipal, regional, and central-government GIS programs, as well as for utility, transport, and private enterprises that have grown past the file-geodatabase threshold. The work is the same in every case: an audited inventory, a governed ArcGIS Enterprise core, a services-not-files delivery model, a cloud-native deployment, and an integration fabric that turns the GIS into a load-bearing part of the agency’s operations rather than a map-production department.

If you operate a public-sector GIS program and the architecture above does not match what you have today, that gap is the work.

TL;DR — Proxy Token Manager (PTM) is a reverse proxy and operations console that adds per-customer API tokens, referrer and IP allowlists, real-time audit logging, rate limiting, and auto-generated developer documentation to ArcGIS Enterprise Map, Feature, Image, and Vector Tile Services. It deploys in front of ArcGIS Server and Portal for ArcGIS without changing the underlying GIS stack, and it does so with sub-millisecond proxy overhead that the dashboard proves on every page view.

Public institutions sit on some of the most useful geospatial data in the country — parcel records, infrastructure layers, zoning, environmental coverage, basemap tiles. Sharing that data with partner agencies, contractors, and citizen-facing applications is not the hard part. Sharing it safely — with per-customer authentication, queryable audit trails, enforceable usage policies, and verifiable performance — is the hard part. Proxy Token Manager is the layer that sits between your ArcGIS Enterprise services and everyone who consumes them, and turns that hard part into operational routine.

What Is Proxy Token Manager?

Proxy Token Manager (PTM) is a token-aware reverse proxy and operations console for ArcGIS Enterprise services. It intercepts every HTTP request to your ArcGIS Map Services, Feature Services, Image Services, and Vector Tile Services; validates the request against a per-customer API token, referrer policy, and optional IP allowlist; forwards approved traffic to the upstream ArcGIS Server endpoint; and writes a structured record of the transaction to an auditable PostgreSQL database. The result is a single, unified access control plane in front of ArcGIS services that historically have lived behind ad-hoc URL secrets and good intentions.

PTM does not replace Portal for ArcGIS, ArcGIS Server, or any part of your existing Esri stack. It is a thin governance layer that wraps the services you already publish, and it coexists cleanly with native ArcGIS token authentication, federated identity, and existing reverse proxies.

ArcGIS Enterprise Security Challenges PTM Addresses

Open services are not the same as governed services

Most ArcGIS Enterprise deployments end up with a small population of services exposed for partner agencies, contractors, regional offices, or public-facing web maps. The original sharing decision was deliberate. The downstream sprawl — unknown referrers consuming the service, unrotated API keys, no usage visibility per consumer — was not. PTM gives that sprawl a clear perimeter, with per-customer tokens, per-customer referrer allowlists, and per-customer telemetry.

Audit logging is non-negotiable in the public sector

Regulators, internal information-security teams, and procurement reviews increasingly ask the same question of GIS operators: who accessed which dataset, when, and from where? If the answer requires a forensic NGINX access-log dive, the answer is effectively “we don’t know.” PTM stores per-request audit records — timestamp, source IP, customer identity, requested service path, HTTP status code, response time — in a queryable database with a configurable retention horizon (seven days to ten years).

Customer onboarding is the silent operational tax

Every new partner that integrates with an ArcGIS service generates a back-and-forth thread about service URLs, authentication parameters, framework-specific code samples, and rate-limit expectations. PTM compresses that thread into a single per-customer PDF that the operator generates with one click — already populated with the customer’s API key, their assigned services, and copy-paste integration code for the ArcGIS JavaScript SDK, Leaflet, and OpenLayers.

API token lifecycles drift without tooling

Long-lived API keys are a known security liability. Short-lived keys are an operational headache without dedicated tooling. PTM treats expiry, warning windows, and rotation as first-class workflow steps so the operator stays ahead of the lifecycle instead of chasing it.

Capabilities

1. Token-Based Access Control for ArcGIS Services

Every customer in PTM gets a unique API token that the proxy validates on every request to a bound ArcGIS service. Each token carries an explicit expiry policy (one day, one month, one year, or non-expiring), an allowlist of referrer domains the request must originate from, and optionally an IP allowlist for service-to-service deployments. Tokens can be rotated in place without taking the upstream ArcGIS service offline, and expired customers stop receiving traffic the moment their window closes — no manual cleanup required.

2. Real-Time Audit Logging and Operational Metrics

The PTM dashboard surfaces a thirty-day request timeline, current-day request volume, active-customer count, and bound-layer count at a glance. Per-customer drill-downs expose the full request history with filtering by time window, HTTP status, and source IP, plus a top-IPs report so the operator sees exactly which networks are consuming a given service. Every event is also written as structured JSON to the application log stream, ready for ingestion into Loki, Elasticsearch, CloudWatch, or any centralized observability platform.

3. Rate Limiting and Per-Customer Usage Policy

Per-customer rate limits prevent any single integration from consuming a disproportionate share of your ArcGIS Server capacity. Combined with the audit log, rate limits give operators the data they need for capacity planning, billing, and service-level negotiation with downstream consumers.

4. Auto-Generated Customer Onboarding PDFs

For every customer, PTM produces a branded PDF guide containing the assigned API key, expiry timeline, the proxy paths for each bound service, rate-limit details, and copy-paste integration code samples for the three most common map clients in production today: the ArcGIS JavaScript SDK, Leaflet, and OpenLayers. The integration story for a new partner becomes a single PDF and a calendar invite — not a week of email.

5. Lifecycle Automation

PTM ships with the operational details that consume real time in unmanaged setups: configurable expiry-warning thresholds with dashboard banners that flag customers whose tokens lapse within the operator’s chosen window, automatic NGINX configuration regeneration and reload when a layer is bound or unbound, an audit-retention cron that prunes log records past the configured horizon, and a token expirer that revokes access on schedule. The system maintains itself between operator interventions.

ArcGIS Proxy Performance: How Much Latency Does PTM Add?

The first question every GIS team asks about a proxy is the right one: what does this cost in latency? PTM answers it on the dashboard, in plain numbers, without asking anyone to take it on faith. The operations view shows the rolling twenty-four-hour average response time of requests that traverse the proxy alongside the equivalent average for direct-to-upstream ArcGIS Server traffic. In well-tuned deployments the gap is measured in fractions of a millisecond — well below the threshold at which any human or downstream system can perceive a difference. The product proves its own performance characteristic every time the operator opens it.

Who Proxy Token Manager Is For

• Municipal and regional government GIS teams that share infrastructure, parcel, and environmental layers with multiple internal departments and external partners.
• Enterprise ArcGIS Server and Portal for ArcGIS operators who need a single, auditable boundary in front of a portfolio of services without changing the underlying ArcGIS deployment.
• Information-security and compliance functions that require provable, queryable evidence of who accessed which dataset and when.
• API platform and developer-experience teams running geospatial services for multi-tenant consumption who need per-customer policy, per-customer documentation, and per-customer telemetry without building it themselves.
• Utility, telecom, and transport operators publishing operational GIS data to contractors and field crews who need scoped, time-bound access.

How PTM Compares to Native ArcGIS Token Authentication

Native ArcGIS token authentication is excellent at what it was designed for: authenticating named users and applications inside the Esri identity model. It was not designed to give operators a per-consumer audit trail across a portfolio of public-facing services, to issue and rotate scoped tokens for external partners, to enforce referrer and IP allowlists per consumer, or to generate consumer-specific developer documentation. PTM does not replace native ArcGIS tokens — it complements them with a governance and operations layer optimized for multi-tenant, externally consumed services.