Hi, Amila. We do not mandate the use of ApisixRoute or Ingress. Even though Ingress does not natively support extension points, it can still configure plugins using annotations [1]. However, ApisixRoute is indeed a CRD resource that aligns more closely with the APISIX concept. Its advantage lies in sharing many configuration options with APISIX, thereby reducing the friction cost of understanding.
For question 1, as long as you can configure the plugin however you like, you can achieve functionality similar to the original code snippet. We support configuring plugins on HTTPRoute/Ingress/ApisixRoute. Since the Ingress standard has been frozen and will not see further development in the foreseeable future, you should prioritize using the Gateway API HTTPRoute (it's a popular standard), followed by ApisixRoute and other CRDs, and only resort to Ingress when absolutely necessary. For question 2, APISIX Ingress Controller (AIC) currently does not support ingress-nginx annotations [1]. However, it provides its own annotation support. AIC will transcribe these annotations into APISIX plugin configurations and apply them. The scope of annotations is limited, so directly configuring plugins is sometimes a more straightforward approach. This allows you to clearly understand what is configured, where it takes effect, and whether it meets expectations. APISIX enables hot-loading for many configurations, allowing updates to routes and upstream settings without reloading Nginx workers. Certain unsupported hot-loading features—such as the buffering you mentioned require pre-start configuration. You must configure those Nginx directives within your Helm chart. Currently, only the request body size [3] and request buffer [4] can be dynamically configured via plugins. Other settings only support static configuration. However, some workarounds supported by NGINX, such as the upstream x-accel-buffering response header, are still supported. [1] https://apisix.apache.org/docs/ingress-controller/reference/apisix-ingress-controller/annotation/ [2] https://artifacthub.io/packages/helm/apisix/apisix?modal=values&path=apisix.nginx.configurationSnippet [3] https://apisix.apache.org/docs/apisix/plugins/client-control/ [4] https://apisix.apache.org/docs/apisix/plugins/proxy-control/ On Fri, Feb 6, 2026 at 2:57 AM Amila De Silva via dev <[email protected]> wrote: > Hi Devs, > > We are currently evaluating APISIX as a replacement for the NGINX Ingress > Controller and are in the process of migrating a few existing Ingress > resources. We would appreciate your recommendation on the best approach for > this migration. > > We mainly have two types of Ingress resources: > > *1. Ingresses with custom Lua routing logic* > These use annotations such as > nginx.ingress.kubernetes.io/server-snippet and > nginx.ingress.kubernetes.io/configuration-snippet > to inject custom Lua logic for routing and redirection. > > *2. Vanilla Ingresses with only annotations* > These do not contain custom processing but use annotations such as > nginx.ingress.kubernetes.io/client-body-buffer-size and > nginx.ingress.kubernetes.io/client-header-buffer-size > to enforce limits and restrictions. > > Based on the documentation, my understanding is: > > - > > The first type should be migrated to *ApisixRoute* resources, where Lua > logic can be implemented through custom plugins or serverless plugins. > - > > The second type *might* be represented using standard Ingress resources. > However, I could not find a clear mapping between NGINX annotations and > APISIX annotations/plugins, so I am unsure whether these can remain as > Ingresses or also need to move to ApisixRoute. > > Could you please advise: > > - > > Whether the above understanding is correct? > - > > The recommended way to migrate NGINX annotations such as buffer limits? > - > > Whether vanilla Ingress resources are expected to work reliably in > APISIX without switching to ApisixRoute? > > Thanks in advance for your guidance. > > Best regards, > Amila > > -- > *Amila De Silva* > Software Architect | Associate Director, Engineering - WSO2 Inc. > (m) +94 775119302 | (e) [email protected] > <http://wso2.com/signature> >
